Azure SQL Database actualmente tiene tres niveles de servicio para elegir para su carga de trabajo. Estos niveles consisten en Básico, Estándar y Premium. Basic solo admite un tamaño de 5 DTU. Premium comienza en 125 DTU y sube a 4,000 DTU. El nivel Premium es el nivel superior creado para cargas de trabajo de E/S más altas y proporciona una latencia más baja por E/S y un orden de magnitud más de IOPS por DTU que en el nivel Estándar.
Antes de agosto de 2017, el nivel Estándar solo admitía tamaños de DTU entre 15 y 100 DTU. Actualmente disponibles en versión preliminar hay nuevos niveles de rendimiento y complementos de almacenamiento que ofrecen beneficios de optimización de precios para cargas de trabajo con uso intensivo de CPU. Con eso, el nivel Estándar ahora admite hasta 3000 DTU.
En este punto, puede que te estés preguntando qué es exactamente una DTU. Una DTU es una unidad de transacción de base de datos y es una combinación de CPU, memoria y E/S de registro de datos y transacciones. (Andy Mallon, @AMtwo, recientemente abordó esto en "¿Qué diablos es una DTU?") Puede alcanzar su límite de DTU maximizando la CPU, la memoria o las E/S.
Anteriormente, el nivel Estándar solo ofrecía 4 niveles:15, 30, 50 y 100 DTU, con un límite de tamaño de base de datos de 250 GB, con disco estándar. Si tenía una base de datos de más de 250 GB, pero no necesitaba más de 100 DTU para CPU, memoria o E/S, estaba obligado a pagar un precio Premium solo por el tamaño de la base de datos. Con los nuevos cambios, ahora puede tener una base de datos de hasta 1 TB en el nivel Estándar; solo tienes que pagar el almacenamiento extra. Actualmente, el almacenamiento se factura a $0.085/GB durante la versión preliminar. Aumentar del tamaño incluido de 250 GB a 1 TB aumenta en 774 GB a un costo de $65,79 por mes.
Los nuevos tamaños de DTU de vista previa estándar admiten opciones de 200, 400, 800, 1600 y 3000 DTU. Si tiene una carga de trabajo de base de datos de SQL Server que está más vinculada a la CPU que a la E/S, estas opciones de nivel Estándar tienen el potencial de ahorrarle mucho dinero; sin embargo, si su carga de trabajo está limitada por E/S, el nivel Premium superará al nivel Estándar.
Decidí probar dos cargas de trabajo diferentes para ver las diferencias entre los niveles Estándar y Premium. Quería crear una prueba simple y reproducible para que otros puedan intentar validar por sí mismos. Para mi primera prueba, quería generar una combinación saludable de CPU y E/S. Esperaba impulsar más CPU que E/S y poder demostrar que el nivel Estándar ampliado superaría al nivel Premium con el mismo tamaño de DTU. No obtuve exactamente los resultados que esperaba.
Para configurar esta demostración, creé una tabla con tres columnas GUID, inserté 1 millón de filas y luego actualicé dos de las tres columnas con nuevas ID. El código de ejemplo está a continuación:
CREATE TABLE dbo.TestTable ( Table_id UNIQUEIDENTIFIER DEFAULT NEWID(), Customer_id UNIQUEIDENTIFIER DEFAULT NEWID(), Cust_Name VARCHAR(40) DEFAULT CAST(NEWID() AS VARCHAR(40)) ); SET NOCOUNT ON; GO INSERT INTO dbo.TestTable DEFAULT VALUES; GO 1000000 CREATE CLUSTERED INDEX [ClustTestTable] ON [dbo].[TestTable] ( [Table_id] ASC, [Customer_id] ASC ); SET STATISTICS TIME ON; UPDATE TestTable SET Table_id = NEWID(), Customer_id = NEWID();
A medida que realicé la serie de pruebas, el rendimiento mejoró constantemente en el nivel Estándar hasta que llegué a la opción S12 donde, curiosamente, la CPU y el tiempo transcurrido aumentaron. Realicé la prueba varias veces y S12 fue consistentemente de 54 segundos. Está bastante claro con mi primera prueba, que el nivel Premium superó al nivel Estándar. Por ejemplo, el S9 y el P2 son los más cercanos en el tiempo; sin embargo, el tamaño de la DTU para el estándar es de 1600 en comparación con 250 para el P2. Esta prueba trata más sobre las capacidades de E/S. El siguiente gráfico muestra el tamaño, el nivel de DTU, el costo, el tiempo de CPU, el tiempo transcurrido y el tiempo en segundos para cada prueba:
Mientras se ejecutaban las pruebas, observé en el tablero del monitor que la E/S de datos y el porcentaje de E/S de registro eran la fuerza impulsora detrás del porcentaje de DTU. El siguiente gráfico fue de una ejecución en una base de datos S4:
Luego decidí probar otra serie de pruebas que serían más pesadas para la CPU. Para esa prueba utilicé el siguiente script:
SET STATISTICS TIME ON;
SELECT SUM(CONVERT(BIGINT, t1.object_id)
+ CONVERT(BIGINT, t2.object_id)
+ CONVERT(BIGINT, t3.object_id)
+ CONVERT(BIGINT, t4.object_id))
FROM sys.objects t1
CROSS JOIN sys.objects t2
CROSS JOIN sys.objects t3
CROSS JOIN sys.objects t4; Lo que observé en el tablero del monitor en esta serie de pruebas es que el porcentaje de CPU fue el único factor que impulsó el porcentaje de DTU. A medida que realicé la serie de pruebas en el nivel Estándar, la prueba pareció estabilizarse en aproximadamente 27 segundos y comenzó en el tamaño S4. Lo que me pareció extraño es que un S4 a 200 DTU tardó 27 segundos en completarse y el P2 correspondiente a 250 DTU tardó 38 segundos; un P4 a 500 DTU fue más comparable. Si observamos el diferencial de costos de esta demostración, un S4 durante la versión preliminar solo costó $150,01, mientras que un P4 costó $1860; el S4 proporciona un ahorro de costos de poco más de $1,700. Imaginemos que un P2 a 250 DTU se desempeñó como esperábamos; un P2 cuesta $930 y todavía costaría $780 más que un S4.
Los resultados completos de todas las pruebas en la segunda demostración se incluyen en el siguiente cuadro:
A diferencia de la primera demostración, esta fue 100% impulsada por CPU. Traté de incluir una unión cruzada adicional, pero la demostración tardó horas por sesión en lugar de minutos. Para una prueba futura, intentaré idear algunos escenarios adicionales que impulsen una carga de trabajo de OLTP más realista; uno que es más CPU, y otro que es más límite de E/S, y luego una mezcla decente de los dos.
Puede ver en el siguiente gráfico que, en esta ejecución contra una base de datos S4, la CPU se disparó en casi un 50 %, mientras que el porcentaje de DTU coincidió exactamente:
De las dos cargas de trabajo diferentes que probé, es muy evidente que si tiene una carga de trabajo de E/S significativa, necesitará el nivel Premium, pero si su carga de trabajo está principalmente vinculada a la CPU sin necesidades de E/S significativas, mayor Los niveles estándar pueden brindarle ahorros sustanciales en comparación con el nivel Premium.
Si está considerando una migración a Azure SQL Database, la calculadora de DTU es un excelente lugar para comenzar a tener una idea de un punto de partida para el dimensionamiento; sin embargo, en el momento de escribir este artículo, la calculadora de DTU no tiene en cuenta el nivel estándar ampliado. Lo bueno de la calculadora de DTU es que desglosará la CPU, las IOP y la utilización de registros para informarle cuál es el factor determinante para la recomendación del nivel de DTU. Por ejemplo, ejecuté la última demostración en una máquina virtual de 4 vCPU y 4 GB, y la calculadora de DTU recomendó una P2. Cuando elegí "ver más detalles", recibí los siguientes mensajes.
Nivel de servicio/Nivel de rendimiento para CPU :en función únicamente de la utilización de la CPU, le recomendamos que migre su carga de trabajo de SQL Server a Premium:P2. Este nivel de servicio/nivel de rendimiento debería cubrir aproximadamente el 100,00 % de la utilización de su CPU.
Nivel de servicio/Nivel de rendimiento para Iops :en función únicamente de la utilización de Iops, le recomendamos que migre su carga de trabajo de SQL Server a Basic. Este nivel de servicio/nivel de rendimiento debería cubrir aproximadamente el 89,92 % de su utilización de Iops.
NOTA:Aproximadamente el 10,08 % de su carga de trabajo corresponde a un Nivel de servicio/Nivel de rendimiento superior. Después de migrar su base de datos a Azure, debe evaluar el rendimiento de su base de datos siguiendo las instrucciones mencionadas en la sección de información anterior.
Nivel de servicio/Nivel de rendimiento para Log :en función únicamente de la utilización de registros, le recomendamos que migre su carga de trabajo de SQL Server a Basic. Este nivel de servicio/nivel de rendimiento debería cubrir aproximadamente el 100,00 % de la utilización de su registro.
Dado que sé que esta carga de trabajo depende en gran medida de la CPU, si no puedo ajustar la carga de trabajo para disminuir el requisito de CPU, tengo hasta 3000 DTU disponibles en el nivel Estándar. En lugar de gastar $930 al mes en un P2 con 250 DTU, un S4 con 200 DTU a $150 al mes (o un S6 con 400 DTU a $300,02 al mes) sería una opción mucho más económica.
En conclusión, hay herramientas disponibles para ayudarlo a determinar un buen punto de partida para el tamaño de sus migraciones de Azure SQL Database; sin embargo, el mejor método es probar su carga de trabajo. La migración de una copia de su base de datos de producción, la captura de una carga de trabajo de producción y la reproducción de esa carga de trabajo en Azure SQL Database le brindarán una mejor comprensión del tamaño de DTU que realmente necesita.
