Exportar (0) Imprimir
Expandir todo

Versión preliminar Basic, Standard y Premium para Base de datos SQL de Azure

Actualizado: mayo de 2014

Autores: Conor Cunningham, Kun Cheng, Jan Engelsberg

Revisores técnicos: Morgan Oslake, Joanne Marone, Keith Elmore, José Batista-Neto, Rohit Nayak

Además de Premium, Base de datos SQL de Azure ha comercializado dos nuevos niveles de servicio, Basic y Standard. Mediante el control estricto de la cantidad de recursos de su Base de datos SQL de Azure y sus réplicas secundarias, el nivel de servicio Premium ofrece un rendimiento más predecible para aplicaciones en la nube. Base de datos SQL de Azure extiende este concepto al nuevo nivel de servicio Standard para ofrecer una mayor predicción del rendimiento para bases de datos con menores requisitos de rendimiento con respecto al nivel de servicio Premium. El nivel de servicio Basic está diseñado para cumplir los requisitos de rendimiento para bases de datos de menor coste.

Este documento proporciona instrucciones que le ayudarán a determinar si el nivel de servicio que está disponible en esta versión preliminar es adecuado para su aplicación y proporciona recomendaciones para optimizar la aplicación con el fin de sacar el máximo partido de su Base de datos SQL de Azure. Se incluyen las secciones siguientes:

Información previa sobre Base de datos SQL de Azure

¿Qué diferencia hay en los nuevos niveles de servicio?

Razones para usar los nuevos niveles de servicio

Descripción del uso de recursos

Optimizar la aplicación

Conclusión

Para entender cómo los niveles de servicio Basic, Standard y Premium mejoran el servicio existente de Base de datos SQL de Azure, es conveniente conocer bien Base de datos SQL de Azure. En la actualidad, los clientes eligen Base de datos SQL de Azure por diversos motivos. Un motivo es evitar el largo ciclo de compra e instalación de hardware: Base de datos SQL de Azure permite crear y quitar bases de datos sobre la marcha sin esperar a que se apruebe un pedido de compra, lleguen los equipos, se actualicen la alimentación y la refrigeración, o se realice la instalación. Microsoft se encarga de todo ello y reduce considerablemente el tiempo necesario para hacer realidad una idea al aprovisionar hardware según la demanda agregada en cada uno de nuestros centros de datos. Esto puede ahorrar semanas o incluso meses al negocio de un cliente respecto a la compra e implementación de hardware manualmente.

Microsoft también incluye muchas características automáticas de administración en Base de datos SQL de Azure como alta disponibilidad automática, equilibrio de carga y administración integrada.

  • Alta disponibilidad (HA) automática

    Base de datos SQL de Azure mantiene al menos tres réplicas de cada base de datos de usuario e incorpora lógica para confirmar automáticamente cada cambio de forma sincrónica en un quórum de las réplicas. Esto garantiza que ningún error en un único equipo produzca pérdida de datos. Además, cada réplica se coloca en diferentes bastidores de hardware de forma que la pérdida de alimentación eléctrica o de conmutadores de red no afecte a la base de datos. Por último, incorpora lógica para volver a generar las réplicas automáticamente si se pierde un equipo de modo que el sistema conserva automáticamente las propiedades de estado deseadas aunque se produzcan errores en un equipo. Estos mecanismos impiden el laborioso proceso que se necesita hoy en día para instalar y configurar soluciones de alta disponibilidad. El hecho de tener una solución preconfigurada de HA para los datos suprime otro quebradero de cabeza importante para la generación de una solución de base de datos crítica mediante técnicas tradicionales.

  • Equilibrio de carga

    A diferencia de las máquinas virtuales tradicionales, Base de datos SQL de Azure también contiene un mecanismo para equilibrar la carga entre varios equipos automáticamente. El equilibrador de carga supervisa dinámicamente el uso de los recursos de un clúster y mueve réplicas de la base de datos a otros equipos del clúster para compartir la carga entre varios usuarios de forma dinámica y equitativa. Esto amplía la capacidad a petición de la base de datos y permite a un usuario considerar los requisitos de capacidad para cada base de datos de forma independiente, ya que el equilibrador de carga podrá migrar las bases de datos ocupadas unas lejos de otras. Al crear soluciones que abarcan muchas bases de datos, esta lógica proporciona una capa de abstracción que permite a un cliente centrarse en las necesidades de capacidad de cada base de datos en lugar de las limitaciones de tamaño específicas de una máquina virtual.

  • Administración integrada

    Base de datos SQL de Azure se ejecuta como un servicio. Esto significa que hay objetivos de tiempo de actividad definidos para cada base de datos, lo que evita períodos de tiempo de inactividad prolongados por tareas de mantenimiento. Microsoft proporciona una solución de un solo proveedor para el servicio, lo que significa que solo hay una compañía a la que llamar en caso de que surja algún problema. Microsoft también actualiza el servicio continuamente, agregando características y capacidad, y encontrando maneras de mejorar la experiencia en todas las actualizaciones que realiza. Las actualizaciones se realizan de forma transparente y sin tiempo de inactividad, lo que significa que están integradas en nuestro mecanismo normal de conmutación por error de HA. Esto permite a los clientes aprovechar las nuevas características inmediatamente una vez que se anuncia su disponibilidad en lugar de tener que esperar a que se actualice un servidor en algún momento futuro con el tiempo de inactividad correspondiente que ello supone.

Todas estas capacidades se entregan en todos los niveles de servicio, comenzando a un precio básico reducido de unos cuantos dólares al mes. Esto es mucho menos de lo que costaría adquirir y ejecutar su propio servidor, lo que significa que incluso el proyecto más pequeño puede beneficiarse de Azure sin gastar mucho dinero.

Microsoft ha trabajado estrechamente con diversos clientes durante su incorporación inicial a Base de datos SQL de Azure para saber cómo utilizaban el servicio e informar de ello a nuestro equipo de ingeniería para planear futuras características. Durante ese tiempo, descubrimos que a algunos tipos de clientes les parecía realmente que el conjunto de características satisfacía sus necesidades correctamente. Por ejemplo, las nuevas empresas que desarrollan nuevos servicios en la nube decían con frecuencia que la combinación de capacidad a petición y la mejor sobrecarga administrativa simplificaba sus vidas y les permitía dedicar su tiempo a su negocio principal. Otros clientes tenían problemas en algunas áreas relacionadas con los requisitos de rendimiento, quizás para atender una API central en una solución grande de base de datos de niveles múltiples, que el servicio Base de datos SQL de Azure no resolvía actualmente. Los comentarios eran que aunque algunos clientes estaban dispuestos a aceptar una variación de rendimiento mayor para conseguir un precio muy bajo, otros clientes estaban más interesados en garantías de rendimiento específicas para poder generar más valor con mayor facilidad a partir de estas bases de datos.

Para abordar las necesidades de los clientes, Microsoft introdujo los niveles de servicio Basic, Standard y Premium, actualmente en versión preliminar pública. Cada nivel de servicio tiene uno o más niveles de rendimiento que proporcionan la capacidad de ejecutar bases de datos de manera predecible. La capacidad se describe en unidades de rendimiento de base de datos (DTU). La tabla siguiente muestra los niveles de servicio, los niveles de rendimiento y la DTU:

 

Nivel de servicio

Nivel de rendimiento

DTU

Basic

5

Standard

S1

15

Standard

S2

50

Premium

P1

100

Premium

P2

200

Premium

P3

800

El nivel de servicio Basic está diseñado para proporcionar una buena predicción del rendimiento para cada base de datos hora tras hora. La DTU de una base de datos Basic está diseñada para proporcionar recursos suficientes para bases de datos pequeñas sin varias solicitudes simultáneas a fin de obtener un buen rendimiento.

Para mejorar la predicción del rendimiento y elevar el nivel de las bases de datos con varias solicitudes simultáneas como aplicaciones web y de grupo de trabajo, Microsoft ha introducido el nivel de servicio Standard. Con una base de datos de nivel de servicio Standard, los clientes pueden dimensionar su aplicación de bases de datos según un rendimiento predecible minuto a minuto. El nivel de servicio Standard ofrece dos niveles de rendimiento (S1 y S2) para permitir bajar o subir de nivel en función de sus necesidades.

La capacidad principal con respecto al rendimiento del nivel de servicio Premium es el rendimiento predecible segundo a segundo para cada base de datos Premium. El uso del nivel de servicio Premium permite a los clientes dimensionar su aplicación de bases de datos en función de una carga pico para dicha base de datos en cuestión y elimina aquellos casos en los que la variación de rendimiento puede hacer que las consultas pequeñas tarden más tiempo del esperado en operaciones sensibles a la latencia. Este modelo puede simplificar considerablemente los ciclos de desarrollo y validación de productos necesarios para las aplicaciones que necesitan hacer declaraciones firmes sobre las necesidades máximas de recursos, variación de rendimiento o latencia de las consultas. También permite migrar algunas aplicaciones locales sin necesidad de realizar cambios significativos, ya que es una experiencia más próxima a la experiencia aislada tradicional que se daba por supuesto en esas aplicaciones cuando se compilaron inicialmente.

De manera similar al nivel de servicio Standard, el nivel de servicio Premium permite elegir entre distintos niveles de rendimiento en función del aislamiento que desee un cliente.

Las configuraciones del nivel de rendimiento para Standard y Premium permiten al cliente pagar solo por la capacidad que necesita y ampliar o reducir la capacidad a medida que cambie una carga de trabajo. Por ejemplo, si la carga de trabajo de la base de datos es elevada durante la época de compras de vuelta al colegio, puede aumentar el nivel de rendimiento de la base de datos durante ese período de tiempo y reducirlo una vez que termine. Esto permite a los clientes minimizar lo que pagan optimizando su entorno de nube según la estacionalidad de su empresa. Este modelo también es adecuado para los ciclos de lanzamiento de productos de software. Un equipo de pruebas puede asignar capacidad mientras realiza series de pruebas y liberar esa capacidad una vez completadas las pruebas. Estas solicitudes de capacidad encajan bien con el modelo de pago según la capacidad que se necesita y evitan el pago por recursos dedicados que casi nunca se utilizan. Esto proporciona una experiencia de rendimiento mucho más cercana al modelo tradicional de hardware dedicado que muchos clientes de Microsoft han utilizado con SQL Server. Debe permitir la ejecución de un conjunto mayor de aplicaciones más fácilmente en Base de datos SQL de Azure.

Si bien cada carga de trabajo puede ser diferente, el objetivo de los nuevos niveles de servicio es proporcionar una predicción del rendimiento alta para distintos niveles de rendimiento. Esto permite a los clientes con una gran escala de requisitos de recursos para sus bases de datos trabajar en un entorno de computación más dedicado.

He aquí algunos escenarios comunes en los que se aplicaría la característica Nivel de servicio Basic:

  • Introducción a Base de datos SQL de Azure: a menudo, las aplicaciones en desarrollo no necesitan altos niveles de rendimiento. Las bases de datos Basic proporcionan un entorno ideal de desarrollo de bases de datos a un precio reducido.

  • Base de datos con un solo usuario: las aplicaciones que asocian un solo usuario a una base de datos normalmente no tienen grandes requisitos de simultaneidad y rendimiento. Las aplicaciones con estos requisitos son candidatas al nivel de servicio Basic.

He aquí algunos escenarios comunes en los que se aplicaría la característica Nivel de servicio Standard:

Base de datos con varias solicitudes simultáneas: las aplicaciones que ofrecen servicio a más de un usuario a la vez, como los sitios web con tráfico moderado o aplicaciones departamentales que requieren una cantidad de recursos mayor son buenos candidatos al nivel de servicio Standard.

He aquí algunos escenarios comunes en los que se aplicaría la característica Nivel de servicio Premium:

  • Carga máxima elevada: una aplicación que necesita mucha CPU, memoria o E/S para completar sus operaciones. Por ejemplo, si se sabe que una operación de base de datos utiliza varios núcleos de CPU durante un período de tiempo prolongado, es candidata a utilizar bases de datos Premium.

  • Muchas solicitudes simultáneas: algunas aplicaciones de base de datos atienden muchas solicitudes simultáneas, por ejemplo al ofrecer servicio a un sitio web con un volumen de tráfico alto. Los niveles de servicio Basic y Standard tienen limites en la cantidad de solicitudes simultáneas. Las aplicaciones que requieren más conexiones necesitarían elegir un tamaño de reserva suficiente para controlar el número máximo de solicitudes necesarias.

  • Latencia baja: algunas aplicaciones necesitan garantizar una respuesta de la base de datos en un tiempo mínimo. Si se llama a un procedimiento almacenado determinado como parte de una operación de cliente más amplia, puede ser necesario volver de esa llamada en no más de 20 milisegundos el 99 % del tiempo. Este tipo de aplicación se beneficiará de las bases de datos Premium para asegurarse de que hay capacidad de proceso disponible.

Para obtener más detalles sobre los escenarios comunes que pueden provocar problemas de rendimiento cuando se utiliza Base de datos SQL de Azure, vea Base de datos SQL de Azure y SQL Server: comparación y diferencias de rendimiento y escalabilidad.

El nivel exacto que necesitará depende de los requisitos de carga máxima para cada dimensión de recursos. Algunas aplicaciones pueden utilizar pocas cantidades de un recurso pero tener requisitos significativos de otro.

Los nuevos niveles de servicio se estructuran de la siguiente manera:

 

Nivel de servicio/nivel de rendimiento DTU Tamaño máximo de la BD Subprocesos de trabajo máximos Sesiones máximas Predicción

Basic

5

2 GB

20

100

Bueno

Standard/S1

15

250 GB

50

200

Mejor

Standard/S2

50

250 GB

100

500

Mejor

Premium/P1

100

500 GB

200

2,000

El mejor

Premium/P2

200

500 GB

400

4,000

El mejor

Premium/P3

800

500 GB

1,600

16,000

El mejor

En el gráfico siguiente se muestra la utilización de recursos de CPU para una base de datos Premium con nivel de rendimiento P2 durante cada hora de una semana. Este gráfico en concreto empieza el lunes, y muestra 5 días laborables y a continuación un fin de semana en el que hay mucha menos actividad en la aplicación.

Según estos datos, esta base de datos tiene actualmente una carga máxima de aproximadamente el 50% de la CPU en relación con el nivel de rendimiento P2 (el mediodía del martes). Si la CPU es el factor dominante en el perfil de recursos de la aplicación, el cliente puede decidir que el nivel P2 es el nivel de rendimiento adecuado para garantizar que la carga de trabajo se ajuste siempre. Si se espera que una aplicación crezca con el tiempo, tiene sentido permitir cierto colchón de recursos adicional para que la aplicación no supere nunca el límite. Esto ayudará a evitar errores visibles por los cliente porque la base de datos no tenga suficiente potencia para procesar las solicitudes de manera eficaz, especialmente en entornos sensibles a la latencia (como una base de datos que respalda una aplicación que dibuja páginas web en función de los resultados de las llamadas a la base de datos).

Cabe mencionar que otros tipos de aplicación pueden interpretar el mismo gráfico de manera diferente. Por ejemplo, si una aplicación intentara procesar datos de nóminas todos los días y tuviera el mismo gráfico, este tipo de modelo de “proceso por lotes” podría funcionar bien en un nivel de rendimiento P1. El nivel de rendimiento P1 tiene 100 DTU en comparación con los 200 DTU del nivel de rendimiento P2. Esto significa que el nivel de rendimiento P1 proporciona la mitad de rendimiento que el nivel de rendimiento P2. Por lo tanto, el uso del 50% de CPU en P2 equivale al uso del 100% de CPU en P1. Siempre y cuando la aplicación no tenga tiempos de espera, quizás no importe que un trabajo grande tarde 2 o 2,5 horas en completarse en tanto en cuanto se complete hoy. Una aplicación de esta categoría puede utilizar probablemente un nivel de rendimiento P1. Este cliente puede aprovechar el hecho de que hay períodos de tiempo durante el día en los que el uso de recursos es menor, lo que significa que cualquier “carga elevada” se puede retrasar a uno de esos momentos posteriores del día. El nivel de rendimiento P1 puede ser adecuado para ese tipo de aplicación (y ahorrar dinero) siempre y cuando los trabajos puedan completarse a tiempo cada día.

Base de datos SQL de Azure expone información sobre los recursos consumidos por cada base de datos activa en la vista sys.resource_stats de la base de datos maestra de cada servidor. Los datos de la tabla se agregan a intervalos de 5 minutos. Durante la versión preliminar de los niveles de servicio Basic, Standard y Premium, los datos pueden tardar más de 5 minutos en aparecer en la tabla, lo que significa que es mejor usar estos datos para análisis históricos que para análisis en tiempo casi real. La consulta de la vista sys.resource_stats muestra el historial reciente de una base de datos para validar si la reserva seleccionada proporcionó el rendimiento deseado cuando era necesario. En el ejemplo siguiente se muestra cómo se exponen los datos en esta vista:

SELECT TOP 10 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

Nota: Algunas columnas de la tabla se han truncado por problemas de espacio. Vea el tema sys.resource_stats para obtener una descripción completa del resultado.

En esta sección se describen maneras de supervisar el uso de recursos de la Base de datos SQL de Azure y para comparar el uso de recursos actual con los diferentes niveles de rendimiento.

  1. En la vista previa actual, la vista de catálogo sys.resource_stats se ha enriquecido con más información histórica de uso de recursos en el nivel de base de datos. Por ejemplo, para ver el uso de recursos de la semana pasada para la base de datos, "userdb1”, puede ejecutar la consulta siguiente:

    SELECT * 
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND 
          start_time > DATEADD(day, -7, GETDATE())
    ORDER BY start_time DESC;
    
    
  2. Para evaluar cómo de bien se ajusta la carga de trabajo al nivel de rendimiento, debe explorar en profundidad cada aspecto diferente de las métricas de recursos: CPU, lecturas, escritura, número de trabajadores y número de sesiones. Esta es la consulta revisada que usa sys.resource_stats para notificar el promedio y los valores máximos de estas métricas de recursos.

    SELECT 
        avg(avg_cpu_percent) AS 'Average CPU Utilization In Percent',
        max(avg_cpu_percent) AS 'Maximum CPU Utilization In Percent',
        avg(avg_physical_data_read_percent) AS 'Average Physical Data Read Utilization In Percent',
        max(avg_physical_data_read_percent) AS 'Maximum Physical Data Read Utilization In Percent',
        avg(avg_log_write_percent) AS 'Average Log Write Utilization In Percent',
        max(avg_log_write_percent) AS 'Maximum Log Write Utilization In Percent',
        avg(active_session_count) AS 'Average # of Sessions',
        max(active_session_count) AS 'Maximum # of Sessions',
        avg(active_worker_count) AS 'Average # of Workers',
        max(active_worker_count) AS 'Maximum # of Workers'
    FROM sys.resource_stats 
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
  3. Con la información anterior de valores promedio y máximos de cada métrica de recursos, puede evaluar cómo de bien se ajusta la carga de trabajo al nivel de rendimiento que seleccione. En la mayoría de los casos, los valores promedio de sys.resource_stats proporcionan una buena línea base para utilizar con el tamaño de destino. Debe ser su vara de medida principal. Por ejemplo, si usa el nivel de servicio Standard con el nivel de rendimiento S2, los porcentajes de uso promedio para la CPU, lecturas y escrituras están por debajo del 20%, el promedio de trabajadores está por debajo de 50 y el promedio de sesiones está por debajo de 200, la carga de trabajo se podría ajustar al nivel de rendimiento S1. Es fácil ver si la base de datos se ajusta a los límites de trabajadores y sesiones. Para ver si una base de datos se ajusta a un nivel de rendimiento inferior con respecto a la CPU, lecturas y escrituras, divida el número de DTU del nivel de rendimiento inferior entre el número de DTU del nivel de rendimiento actual y multiplique el resultado por 100:



    S1 DTU / S2 DTU * 100 = 5 / 25 * 100 = 20



    El resultado es la diferencia de rendimiento relativa entre los dos niveles de rendimiento expresada en porcentaje. Si su uso no supera este porcentaje, la carga de trabajo podría ajustarse al nivel de rendimiento inferior. Sin embargo, debe examinar todos los intervalos de valores de uso de recursos y determinar, según el porcentaje, con qué frecuencia la carga de trabajo de la base de datos se ajustaría al nivel de rendimiento inferior. La siguiente consulta expresa el porcentaje de ajuste por dimensión de recursos en función del umbral del 20% calculado anteriormente:

    SELECT 
        (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent'
        ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 20 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    
    En función del objetivo de nivel de servicio (SLO) de la base de datos, puede decidir si la carga de trabajo se ajusta al nivel de rendimiento inferior. Si el SLO de la carga de trabajo de la base de datos es del 99,9% y la consulta anterior devuelve valores mayores que 99,9 para las tres dimensiones de recursos, es muy probable que la carga de trabajo se ajuste en el nivel de rendimiento inferior.

    El porcentaje de ajuste también ofrece información sobre si debe pasar al siguiente nivel de rendimiento superior para satisfacer su SLO. Por ejemplo, “userdb1” muestra el siguiente uso para la semana anterior:

     

    Porcentaje promedio de CPU

    Porcentaje máximo de CPU

    24.5

    100.00

    La CPU promedio es aproximadamente un cuarto del límite del nivel de rendimiento, lo que se ajustaría bien al nivel de rendimiento de la base de datos. Sin embargo, el valor máximo muestra que la base de datos alcanza el límite del nivel de rendimiento. ¿Debe pasar al siguiente nivel de rendimiento superior? De nuevo, debe observar cuántas veces la carga de trabajo alcanza el 100% y compararlo con el SLO de la carga de trabajo de la base de datos:

    SELECT 
    (COUNT(database_name) - SUM(CASE WHEN avg_cpu_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'CPU Fit Percent'
    ,(COUNT(database_name) - SUM(CASE WHEN avg_log_write_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Log Write Fit Percent’
    ,(COUNT(database_name) - SUM(CASE WHEN avg_physical_data_read_percent >= 100 THEN 1 ELSE 0 END) * 1.0) / COUNT(database_name) AS 'Physical Data Read Fit Percent'
    FROM sys.resource_stats
    WHERE database_name = 'userdb1' AND start_time > DATEADD(day, -7, GETDATE());
    
    Si la consulta anterior devuelve un valor menor que 99,9 para cualquiera de las tres dimensiones de recursos, debe considerar pasar al siguiente nivel de rendimiento superior o usar técnicas de optimización de la aplicación para reducir la carga en Base de datos SQL de Azure.

  4. El ejercicio anterior también debe tener en cuenta el aumento previsto de la carga de trabajo en el futuro.

En SQL Server local tradicional, el proceso de planear la capacidad inicial suele estar separado del proceso de ejecutar una aplicación en producción. Es decir, la compra de hardware y las licencias asociadas para ejecutar SQL Server se suele hacer por adelantado, mientras que la optimización del rendimiento se hace después. Cuando se usa Base de datos SQL de Azure, en general se recomienda (y, puesto que se factura a los clientes cada mes, es deseable) intercalar el proceso de ejecución y optimización de una aplicación. El modelo de pago por capacidad a petición permite al cliente optimizar la aplicación para utilizar los recursos mínimos necesarios ahora en lugar de aprovisionar en exceso hardware en función de suposiciones de planes de crecimiento futuro (que suelen ser bastante incorrectos porque tienen que predecir en un futuro bastante lejano). Algunos clientes pueden decidir no optimizar una aplicación y en su lugar elegir aprovisionar excesivos recursos de hardware. Este enfoque puede tener sentido cuando un cliente no desea realizar cambios en una aplicación clave durante un período de mucha actividad para la aplicación. La optimización de una aplicación puede minimizar los requisitos de recursos y reducir las facturas mensuales cuando se usan los nuevos niveles de servicio en Base de datos SQL de Azure.

Aunque los nuevos niveles de servicio están diseñados para mejorar la estabilidad y la previsibilidad del rendimiento de una aplicación, hay algunas prácticas recomendadas para optimizar la aplicación con el fin de sacar el máximo partido de la característica. Si bien muchas aplicaciones conseguirán importantes mejoras de rendimiento con solo cambiar a un nivel de rendimiento o nivel de servicio superior, no todas las aplicaciones pueden beneficiarse tanto sin una optimización adicional. Las aplicaciones que tienen las características siguientes deben considerar también una optimización adicional para mejorar aún más el rendimiento cuando se utiliza Base de datos SQL de Azure.

  • Aplicaciones que tienen un rendimiento bajo debido a un comportamiento “locuaz”

    Esto incluye aplicaciones que realizan excesivas operaciones de acceso a datos que son sensibles a la latencia de red. Puede ser necesario modificar estas aplicaciones para reducir el número de operaciones de acceso a datos en Base de datos SQL de Azure. Por ejemplo, se puede mejorar la aplicación utilizando técnicas como consultas ad hoc de procesamiento por lotes conjuntas o mover las consultas a procedimientos almacenados. Para obtener más información, vea la sección 'Procesamiento por lotes de consultas' más adelante.

  • Bases de datos con una carga de trabajo intensiva que no se pueden admitir en un solo equipo

    Las bases de datos que superan los recursos del mayor nivel de rendimiento Premium no son buenas candidatas. Estas bases de datos pueden beneficiarse del escalado horizontal de la carga de trabajo. Para obtener más información, vea las secciones 'Particionamiento entre bases de datos' y 'Particionamiento funcional' más adelante.

  • Aplicaciones que contienen consultas no óptimas

    Las aplicaciones, especialmente en la capa de acceso a datos, que tienen consultas poco optimizadas no pueden beneficiarse de la elección de un nivel de rendimiento superior como cabría esperar. Esto incluye consultas que carecen de una cláusula WHERE, en las que faltan índices o que tienen estadísticas anticuadas. Estas aplicaciones se beneficiarán de técnicas estándar de optimización de rendimiento de las consultas. Para obtener más información, vea las secciones 'Índices que faltan' y 'Optimización/sugerencias de consultas' más adelante.

  • Aplicaciones que no tienen un diseño óptimo de acceso a datos

    Las aplicaciones que tienen problemas inherentes de simultaneidad de acceso a datos, como interbloqueos, no pueden beneficiarse de la elección de un nivel de rendimiento superior. Los desarrolladores de aplicaciones deben reducir los ciclos de ida y vuelta en Base de datos SQL de Azure almacenando en memoria caché datos en el cliente con el servicio Caching de Azure u otras tecnologías de almacenamiento en memoria caché. Vea la sección 'Almacenamiento en memoria caché de la capa de aplicación' más adelante.

En esta sección se explican algunas técnicas que puede utilizar para optimizar Base de datos SQL de Azure con el fin de obtener el máximo rendimiento de la aplicación y que esta se pueda ejecutar en el mínimo nivel de rendimiento posible. Varias de las técnicas coinciden con prácticas recomendadas de optimización tradicionales de SQL Server, pero otras son específicas de Base de datos SQL de Azure. En algunos casos, las técnicas tradicionales de SQL Server se pueden ampliar para que funcionen también en Base de datos SQL de Azure si se examinan los recursos consumidos para una base de datos con el fin de encontrar áreas para una mayor optimización.

Un problema frecuente de rendimiento de las bases de datos OLTP está relacionado con el diseño físico de las bases de datos. A menudo, los esquemas de la base de datos se diseñan y entregan sin realizar pruebas a escala (ya sea de carga o de volumen de datos). Desgraciadamente, el rendimiento de un plan de consulta puede ser aceptable a pequeña escala pero se puede degradar sustancialmente cuando se hace frente a los volúmenes de datos del nivel de producción. El origen más común de este problema se debe a la falta de índices adecuados para satisfacer los filtros u otras restricciones de una consulta. A menudo, esto se manifiesta como un recorrido de tabla cuando podría ser suficiente con una búsqueda en índice.

El ejemplo siguiente crea un caso en el que el plan de consulta seleccionado contiene un recorrido cuando bastaría con una búsqueda:

DROP TABLE dbo.missingindex;
CREATE TABLE dbo.missingindex (col1 INT IDENTITY PRIMARY KEY, col2 INT);
DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO dbo.missingindex(col2) VALUES (@a);
    SET @a += 1;
END
COMMIT TRANSACTION;
GO
SELECT m1.col1 
FROM dbo.missingindex m1 INNER JOIN dbo.missingindex m2 ON(m1.col1=m2.col1) 
WHERE m1.col2 = 4;


Base de datos SQL de Azure contiene funcionalidad que ayuda a los administradores de bases de datos de sugerencias a buscar y corregir condiciones frecuentes de índices que faltan. Las vistas de administración dinámica (DMV) integradas en Base de datos SQL de Azure consideran la compilación de consultas en que un índice reduciría considerablemente el costo estimado de ejecutar una consulta. Durante la ejecución de la consulta, hace un seguimiento de la frecuencia con la que se ejecuta cada plan de consulta, así como del intervalo estimado entre el plan de consulta que se ejecuta y uno imaginado donde existía ese índice. Esto permite que un administrador de bases de datos estime rápidamente qué cambios de diseño de la base de datos física podrían mejorar el costo global de la carga de trabajo para una base de datos determinada y su carga de trabajo real.

Se puede utilizar la consulta siguiente para evaluar los posibles índices que faltan.

SELECT CONVERT (varchar, getdate(), 126) AS runtime, 
    mig.index_group_handle, mid.index_handle, 
    CONVERT (decimal (28,1), migs.avg_total_user_cost * migs.avg_user_impact * 
            (migs.user_seeks + migs.user_scans)) AS improvement_measure, 
    'CREATE INDEX missing_index_' + CONVERT (varchar, mig.index_group_handle) + '_' + 
              CONVERT (varchar, mid.index_handle) + ' ON ' + mid.statement + ' 
              (' + ISNULL (mid.equality_columns,'') 
              + CASE WHEN mid.equality_columns IS NOT NULL 
                          AND mid.inequality_columns IS NOT NULL 
                     THEN ',' ELSE '' END + ISNULL (mid.inequality_columns, '')
              + ')' 
              + ISNULL (' INCLUDE (' + mid.included_columns + ')', '') AS create_index_statement, 
    migs.*, 
    mid.database_id, 
    mid.[object_id]
FROM sys.dm_db_missing_index_groups AS mig
INNER JOIN sys.dm_db_missing_index_group_stats AS migs 
    ON migs.group_handle = mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details AS mid 
    ON mig.index_handle = mid.index_handle
ORDER BY migs.avg_total_user_cost * migs.avg_user_impact * (migs.user_seeks + migs.user_scans) DESC

En este ejemplo, se sugiere este índice:

CREATE INDEX missing_index_5006_5005 ON [dbo].[missingindex] ([col2])

Una vez creada, esa misma instrucción SELECT elige ahora un plan diferente que utiliza una búsqueda en lugar de un recorrido, lo que aumenta la eficacia de ejecución como se muestra en el plan de consulta siguiente.

La clave es que la capacidad de E/S de un sistema compartido suele ser más limitada que la de un equipo servidor dedicado. Por tanto, es obligatorio minimizar la E/S innecesaria para sacar el máximo partido del sistema dentro de la DTU de cada nivel de rendimiento de los nuevos niveles de servicio en Base de datos SQL de Azure. Unas opciones adecuadas de diseño de la base de datos física pueden mejorar considerablemente la latencia de las consultas individuales y el rendimiento de las solicitudes simultáneas que puede controlar por unidad de escala, y minimizan los costos necesarios para satisfacer la consulta. Para obtener más información acerca de las DMV de los índices que faltan, vea sys.dm_db_missing_index_details.

El optimizador de consultas de Base de datos SQL de Azure es muy similar al optimizador de consultas tradicional de SQL Server. Muchas de las prácticas recomendadas para optimizar consultas y entender el razonamiento de las limitaciones del modelo del optimizador de consultas son aplicables también a Base de datos SQL de Azure. La optimización de consultas en Base de datos SQL de Azure puede tener la ventaja adicional de reducir las demandas de recursos agregadas y permitir que una aplicación se ejecute con un costo menor que una equivalente sin optimizar, ya que se puede ejecutar en un nivel de rendimiento inferior.

Un ejemplo común en SQL Server y que también se aplica a Base de datos SQL de Azure tiene que ver con la forma en que se "examinan" los parámetros durante la compilación para intentar crear un plan más óptimo. El examen de parámetros es un proceso por el cual el optimizador de consultas considera el valor actual de un parámetro al compilar una consulta con la esperanza de generar un plan de consulta más óptimo. Aunque a menudo esta estrategia puede dar como resultado un plan de consulta que es mucho más rápido que un plan compilado sin conocer los valores de los parámetros, el comportamiento actual de SQL Server/Base de datos SQL de Azure es imperfecto; hay algunos casos en los que el parámetro no se examina y hay otros casos en los que el parámetro se examina pero el plan generado es poco óptimo para todo el conjunto de valores de parámetros de una carga de trabajo. Microsoft incluye las sugerencias de consulta (directivas) para permitir que el cliente especifique un intento más deliberado e invalide el comportamiento predeterminado para el examen de parámetros. A menudo, el uso de sugerencias puede corregir los casos en los que el comportamiento predeterminado de SQL Server/Base de datos SQL de Azure es imperfecto para una carga de trabajo concreta del cliente.

En el ejemplo siguiente se muestra cómo el procesador de consultas puede generar un plan que es poco óptimo para los requisitos de rendimiento y de recursos, y cómo el uso de una sugerencia de consulta puede reducir los requisitos de tiempo de ejecución y de recursos de una consulta en Base de datos SQL de Azure.

Ejemplo de configuración:

DROP TABLE psptest1;
CREATE TABLE psptest1(col1 int primary key identity, col2 int, col3 binary(200));

DECLARE @a int = 0;
SET NOCOUNT ON;
BEGIN TRANSACTION
WHILE @a < 20000
BEGIN
    INSERT INTO psptest1(col2) values (1);
    INSERT INTO psptest1(col2) values (@a);
    SET @a += 1;
END
COMMIT TRANSACTION
CREATE INDEX i1 on psptest1(col2);
GO

CREATE PROCEDURE psp1 (@param1 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 
    WHERE col2 = @param1
    ORDER BY col2;
END
GO

CREATE PROCEDURE psp2 (@param2 int)
AS
BEGIN
    INSERT INTO t1 SELECT * FROM psptest1 WHERE col2 = @param2
    ORDER BY col2
    OPTION (OPTIMIZE FOR (@param2 UNKNOWN))
END
GO

CREATE TABLE t1 (col1 int primary key, col2 int, col3 binary(200));
GO

El código de configuración crea una tabla que contiene una distribución de datos sesgada. El plan de consulta óptimo difiere según el parámetro que se seleccione. Desgraciadamente, el comportamiento de almacenamiento en memoria caché del plan no siempre recompila la consulta según el valor del parámetro más común, lo que significa que es posible que un plan poco óptimo se almacene en memoria caché y se utilice para muchos valores, incluso aunque un plan diferente sería una opción mejor de plan promedio. Después crea dos procedimientos almacenados que son idénticos salvo que uno contiene una sugerencia de consulta especial (el razonamiento se explica a continuación).

Ejemplo (parte 1):

-- Prime Procedure Cache with scan plan
EXEC psp1 @param1=1;
TRUNCATE TABLE t1;

-- Iterate multiple times to show the performance difference
DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp1 @param1=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END

Ejemplo (parte 2; espere 10 minutos antes de intentar esta parte de modo que sea claramente diferente en los datos de telemetría resultantes):

EXEC psp2 @param2=1;
TRUNCATE TABLE t1;

DECLARE @i int = 0;
WHILE @i < 1000
BEGIN
    EXEC psp2 @param2=2;
    TRUNCATE TABLE t1;
    SET @i += 1;
END


Cada parte de este ejemplo intenta ejecutar 1000 veces una instrucción de inserción con parámetros (para generar carga suficiente que destaque en un conjunto de datos de pruebas). Al ejecutar procedimientos almacenados, el procesador de consultas examina el valor del parámetro pasado al procedimiento durante su primera compilación (lo que se conoce como “examen” de parámetros). El plan resultante se almacena en memoria caché y se utiliza para invocaciones posteriores, incluso aunque el valor del parámetro sea diferente. Como resultado, puede que no se utilice el plan óptimo en todos los casos. Algunas veces los clientes necesitan guiar al optimizador para que elija un plan que es mejor para el caso promedio en lugar del caso concreto la primera vez que se compiló la consulta. En este ejemplo, el plan inicial generará un plan de “recorrido” que lee todas las filas para encontrar cada valor que coincide con el parámetro:

Como ejecutamos el procedimiento con el valor 1, el plan resultante era óptimo para 1 pero poco óptimo para todos los demás valores de la tabla. El comportamiento resultante probablemente no sea el deseado si el cliente elige cada plan de forma aleatoria, ya que el plan se ejecutará más despacio y consumirá más recursos.

La ejecución de la prueba con “SET STATISTICS IO ON” muestra el trabajo de recorrido lógico en este ejemplo; puede ver que el plan realiza 1148 lecturas (lo que no es eficaz si el caso promedio es devolver únicamente una fila):

La segunda parte del ejemplo utiliza una sugerencia de consulta para indicar el optimizador que utilice un valor específico durante el proceso de compilación. En este caso, fuerza al procesador de consultas a omitir el valor pasado como parámetro y hace que en su lugar suponga un valor “UNKNOWN”, lo que significa un valor que tiene la frecuencia promedio de la tabla (se omite el sesgo). El plan resultante es un plan basado en búsqueda que es más rápido y utiliza menos recursos, en promedio, que el plan de la parte 1 del ejemplo:

El impacto de esto se puede ver examinando la tabla sys.resource_stats (nota: habrá un retraso desde el momento en que se ejecuta la prueba hasta que se rellenan los datos en la tabla). En este ejemplo, la parte 1 se ejecutó durante el período de tiempo de las 22:25:00 y la parte 2 se ejecutó a las 22:35:00. Observe que el período de tiempo anterior usó más recursos en ese período que el posterior (debido a las mejoras de eficacia del plan).

SELECT TOP 1000 * 
FROM sys.resource_stats 
WHERE database_name = 'resource1' 
ORDER BY start_time DESC

ImportantImportante
Aunque el ejemplo utilizado aquí es pequeño intencionadamente, el impacto de parámetros poco óptimos puede ser considerable, especialmente en bases de datos grandes. En casos extremos, la diferencia puede ser de segundos e incluso horas para los casos rápido y lento.

Los clientes pueden examinar sys.resource_stats para determinar si el recurso de una prueba determinada utiliza más o menos recursos que otra prueba. Al comparar los datos, separe las pruebas el tiempo suficiente para que no se agrupen en el mismo período de tiempo de cinco minutos en la vista sys.resource_stats. Además, tenga en cuenta que el objetivo del ejercicio es minimizar los recursos totales utilizados, no minimizar los recursos máximos. Normalmente, al optimizar un fragmento de código teniendo en cuenta la latencia también se reducirá el consumo de recursos. Cuando se emplean sugerencias de consulta, asegúrese de que los cambios previstos en cualquier aplicación sean necesarios realmente y no afecten negativamente a la experiencia de cualquier persona que utilice una aplicación.

Si una carga de trabajo contiene un conjunto de consultas repetidas, suele tener sentido capturar y validar la idoneidad de esas elecciones del plan ya que probablemente controlarán la unidad mínima de tamaño de recursos necesaria para hospedar la base de datos. Una vez validados, un nuevo examen ocasional de esos planes puede confirmar que no se han degradado. Para obtener más información acerca de las sugerencias de consulta, vea Sugerencias de consulta (Transact-SQL).

Puesto que Base de datos SQL de Azure se ejecuta en hardware estándar, suele haber límites menores de capacidad para una sola base de datos que en una instalación tradicional local de SQL Server. Por tanto, hay varios clientes que utilizan técnicas de particionamiento para repartir las operaciones entre varias bases de datos cuando no caben dentro de los límites de una sola base de datos en Base de datos SQL de Azure. La mayoría de los clientes que usan técnicas de particionamiento en Base de datos SQL de Azure actualmente dividen sus datos en una única dimensión en varias bases de datos. Este enfoque implica entender que a menudo las aplicaciones OLTP realizan transacciones que solo se aplican a una fila o a un pequeño grupo de filas dentro del esquema. Por ejemplo, si una base de datos contiene clientes, pedidos y detalles de pedido (como en la base de datos Northwind de ejemplo tradicional incluida en SQL Server), estos datos se pueden dividir en varias bases de datos agrupando un cliente con la información relacionada de pedido y detalles de pedido, y garantizar que permanece dentro de una única base de datos. La aplicación dividiría los distintos clientes en varias bases de datos, repartiendo la carga eficazmente entre varias bases de datos. Esto permite a los clientes no solamente evitar el límite de tamaño máximo de la base de datos sino también permite que Base de datos SQL de Azure procese cargas de trabajo que son mucho mayores que los límites de los distintos niveles de rendimiento siempre y cuando cada base de datos individual se ajuste a su DTU.

Mientras el particionamiento de la base de datos no reduce la capacidad de recursos agregada de una solución, esta técnica es muy eficaz para admitir soluciones muy grandes repartidas entre varias bases de datos y permite que cada base de datos se ejecute en un nivel de rendimiento distinto para admitir bases de datos “eficaces” muy grandes con requisitos elevados de recursos.

Los usuarios de SQL Server combinan a menudo varias funciones en una única base de datos. Por ejemplo, si una aplicación contiene lógica para administrar el inventario de una tienda, esa base de datos podría contener lógica asociada al inventario, seguimiento de pedidos de compra, procedimientos almacenados y vistas indizadas o materializadas que administraran los informes de fin de mes, y otras funciones. Esta técnica tiene la ventaja de que puede administrar fácilmente la base de datos para operaciones como BACKUP, pero también requiere que el cliente ajuste el tamaño del hardware para administrar cargas máximas en todas las funciones de una aplicación.

Dentro de la arquitectura de escalado horizontal que se emplea dentro de Base de datos SQL de Azure, suele ser beneficioso repartir las distintas funciones de una aplicación entre bases de datos diferentes. Esto permite escalar cada una de ellas de forma independiente. A medida que una aplicación realiza una actividad mayor (y se carga más en la base de datos), esto permite que el administrador elija niveles de rendimiento independientemente para cada función de una aplicación. Lleavada al límite, esta arquitectura permite que una aplicación llegue a ser mayor de lo que un solo equipo estándar puede controlar al repartir la carga entre varios equipos.

En las aplicaciones que tienen acceso a datos en forma de numerosas consultas ad hoc frecuentes, una gran parte del tiempo de respuesta se dedica a la comunicación de red entre la capa de aplicación y la capa de Base de datos SQL de Azure. Aunque la aplicación y Base de datos SQL de Azure residan en el mismo centro de datos, la latencia de red entre los dos se puede magnificar debido al elevado número de operaciones de acceso a datos. Para reducir los ciclos de ida y vuelta de red para estas operaciones de acceso a datos, el desarrollador de aplicaciones debe considerar la posibilidad de procesar por lotes las consultas ad hoc o compilarlas en procedimientos almacenados. El procesamiento por lotes de consultas ad hoc puede enviar varias consultas como un lote grande en un solo recorrido hasta Base de datos SQL de Azure. La compilación de consultas ad hoc en un procedimiento almacenado puede obtener el mismo resultado que el procesamiento por lotes. El uso de un procedimiento almacenado también ofrece la ventaja de aumentar las posibilidades de almacenar en memoria caché los planes de consulta en Base de datos SQL de Azure para las ejecuciones posteriores del mismo procedimiento almacenado.

Algunas aplicaciones realizan muchas operaciones de escritura. En ocasiones, es posible reducir la carga total de E/S de una base de datos si se procesan por lotes las escrituras juntas. Esto suele ser tan sencillo como utilizar transacciones explícitas en lugar de transacciones de confirmación automática dentro de procedimientos almacenados y lotes ad hoc. Para obtener una evaluación de las distintas técnicas que se pueden utilizar, vea Técnicas de procesamiento por lotes para aplicaciones de Base de datos SQL en Azure. Pruebe con su propia carga de trabajo para encontrar el modelo adecuado de procesamiento por lotes, teniendo cuidado para entender que un modelo determinado puede tener garantías de coherencia transaccional ligeramente diferentes. Por último, para encontrar la carga de trabajo adecuada que minimiza el uso de recursos es necesario encontrar la combinación correcta de contrapartidas entre coherencia y rendimiento.

Algunas aplicaciones de base de datos contienen cargas de trabajo con muchas operaciones de lectura. Es posible utilizar capas de almacenamiento en memoria caché para reducir la carga de la base de datos y posiblemente reducir el nivel de rendimiento necesario para admitir una base de datos que usa Base de datos SQL de Azure. Azure Caching (Caching) permite a un cliente que tiene una carga de trabajo con muchas lecturas leer los datos una vez (o quizás una vez por equipo de la capa de aplicación, según cómo esté configurada) y almacenar esos datos fuera de Base de datos SQL de Azure. Esto permite reducir la carga de la base de datos (CPU y E/S de lectura), pero afecta a la coherencia transaccional porque los datos que se leen de la memoria caché pueden estar obsoletos con respecto a los datos de la base de datos. Aunque hay muchas aplicaciones en las que es aceptable una cierta cantidad de incoherencias, esto no es cierto para todas las cargas de trabajo. Debe entender totalmente los requisitos de la aplicación antes de emplear una estrategia de almacenamiento en memoria caché de la capa de aplicación.

La introducción de los nuevos niveles de servicio en Base de datos SQL de Azure permite a los clientes elevar el listón sobre los tipos de aplicaciones que compilan en la nube. Cuando se combina con una optimización diligente de la aplicación, los clientes pueden obtener un rendimiento eficaz y confiable para su aplicación. En este documento se describen técnicas recomendadas para optimizar el consumo de recursos de una base de datos a fin de ajustarse correctamente a uno de los nuevos niveles de rendimiento. La optimización es un ejercicio continuado en el modelo de nube, y los nuevos niveles de servicio y sus niveles de rendimiento permiten a los administradores maximizar el rendimiento a la vez que se minimizan los costes en la plataforma de Microsoft Azure.

Vea también

Mostrar:
© 2014 Microsoft