Comprendiendo las nuevas ediciones de SQLDB (antes SQL Azure)
Por mucho tiempo hemos tenido en Azure dos ediciones o Service Tiers de SQLDB. La web y la business.
La única diferencia práctica de estas dos versiones hoy en día, es que la Web escala su tamaño automáticamente hasta los 5gb. Momento en el cual se bloquea y no sigue aceptando datos. La Business puede llegar hasta 150GB siendo posible fijar límites de crecimiento a los 10, 20, 30, 40 50, y 100GB.
Como aprecian, el foco de estas ediciones era el tamaño. No el performance. De hecho para ambas se tenía un performance estándar que es difícil de medir. Más adelante veremos un estimado de éste.
Entonces basados en el feedback obtenido por parte de los usuarios, hemos introducido unos nuevos Service Tiers que están más enfocados a poder ofrecer un performance predecible. Adicionalmente estos nuevos niveles ofrecen un mayor SLA (desde 99.9% pasamos a 99.99%), bases de datos más grandes (de hasta 500GB) por menos precio y una experiencia mejorada en la facturación donde se puede ver más detalladamente los consumos que ahora no tienen como unidad mínima el día, sino de manera más conveniente, son medidos por hora.
Los niveles actuales sin embargo siguen manteniéndose, pero solo hasta septiembre de 2015. Tiempo suficiente para hacer la migración. De hecho, se pueden seguir creando estos tipos de bases de datos de aquí hasta la fecha de retiro.
Aparte de los cambios mencionados hasta ahora, existe otro cambio sustancial relativo a la escalabilidad de las bases de datos. Con el modelo clásico, esto se lograba a través de Federations. Un mecanismo que si bien es ingenioso y funcional, aún carece de la abstracción necesaria para por ejemplo manejarlo transparentemente desde un ORM como el Entity Framework. Entonces decidimos evolucionar el modelo de federaciones a lo que hoy conocemos como Elastic Scale; una característica que hoy se encuentra en preview y que facilita mucho más el manejo del sharding en las aplicaciones. Así que una vez retiradas las versiones Web y Business en septiembre de 2015, también dejará de soportarse la federación tal y como se conoce hoy en día. Posteriormente estaré publicando un post que nos explica estos conceptos de escalamiento horizontal en detalle.
LOS NUEVOS TIERS
Basic: Enfocado a bases de datos de desarrollo y testing o de aplicaciones de uso infrecuente. En general solo soportan una operación concurrente.
Standard: La mayoría de las aplicaciones en cloud usarán esta opción dado que soporta multiples queries concurrentes.
Premium: Orientada a aplicaciones en las que sabemos que existirá una gran carga transaccional, de concurrencia y de exigencias de continuidad del negocio. Por ejemplo las aplicaciones de misión crítica.
Para medir el performance de estos tres niveles, hemos diseñado una herramienta llamada Azure SQL Database Benchmark (ASDB). Básicamente se usa para ejecutar cargas de tipo OLTP contra los servidores y observar el rendimiento, que se mide en DTUs (Database Throughput Unit): Una medida aplicada sobre una mezcla del rendimiento de CPU, memoria y de lecto escritura, de tal manera que un nivel de performance de 5 DTUs tiene 5 veces más poder que un performance de 1 DTU. Hay que tener en cuenta que un servidor de SQLDB soporta hoy en día hasta 1600DTUs, que son consumibles por todas las bases de datos que hospede (máximo 150). Estos límites pueden ser ampliados, tras poner un caso de soporte, de ser necesario.
Los detalles de cada uno de los tiers y de sus subniveles se encuentran en la siguiente tabla:
Obsérvese que la predictibilidad hace referencia a la capacidad de la DB de emplear siempre el mismo tiempo ejecutando el mismo tipo de operaciones.
En este modelo de SQLDB, es muy fácil cambiar entre los distintos niveles sin tener que suspender la operación de la DB. Ésto siempre será una operación online.
MONITOREO:
Básicamente proveemos dos maneras de ejecutar monitoreo sobre las SQLDB (sin necesidad de usar herramientas de terceros, que obviamente también están disponibles):
1. A través del portal
Se pueden agregar métricas como porcentaje de CPU, porcentaje de lecturas y escrituras en disco. Adicionalmente podemos incluir alertas de acuerdo a éstas mediciones (email).
2. A traves de las Dynamic Management Views en la DB Master del servidor en el que tenemos la SQLDB.
En conclusión, hemos observado cómo hemos introducido nuevos niveles de performance y tamaño para nuestras bases de datos como servicio, de manera que ahora tenemos más flexibilidad y poder para implementar nuestras soluciones de cloud con requerimientos de base de datos.