Windows Azure SQL Database Escalamiento Elástico (Elastic Scale)
by Luis Ramirez
En soluciones de la nube, la edición seleccionada definirá los recursos con los cuales trabajara la base de datos. Los cuales cuando vemos aumento o disminución de carga y/o el servidor podemos revisar si procedemos con la escalación de la base de datos o la distribución en una o más bases de datos.
¿Qué pasaría si esta actividad pudiera ser llevada dinámicamente? Que el aplicativo en base a la carga, pudiera manejar la escalación de la edición de la base de datos y/o distribuir la información en una o más base de datos, todo esto, sin necesidad de realizar cambios adicionales al aplicativo.
Es así como se puede ver al Escalamiento Elástico en Windows Azure SQL Database, donde por medio de las librerías .NET “Elastic Escale” nos permitirán el manejo del escalamiento horizontal o vertical de una solución de base de datos en la nube dinámicamente vía aplicativo en base a la demanda.
Antes de continuar, hay que familiarizarse con los conceptos que integran esta solución:
Shard (Partición).
La unidad (base de datos) donde reside un segmento de una tabla que será particionada ya sea por rango o un campo específico.
Shardlet.
El identificador (llave) por el cual serán particionada la tabla, puede ser de tipo: INT, BIGINT, GUID, VARBINARY
Shard Set.
Conjunto de “N” shards (bases de datos) que representaran la tabla.
Shard Map Manager (Administrador de Mapa de Partición)
Una base de datos que contendrá la metadata de cómo están organizados los shards en la solución.
Gráficamente se puede ver de la siguiente manera:
Escalación Horizontal.
La acción de crear o fusionar nuevos “Shards” donde la estructura será la misma en todas las bases de datos y la información segmentada en base al criterio especificado.
Escalación Vertical
Incremento o decremento de los recursos (cambio de edición) de cada “Shard” en base a la demanda.
Cada shard puede estar en una edición diferente.
El siguiente diagrama nos muestra el desarrollador de un lado y administradores de otro, las extensiones .NET que manejaran serán diferentes. También se ve que dependiendo el tipo de operación, la consulta se puede hacer directamente (shard-local) o se hará un cambio de semántica para que se pueda llevar a cabo (Cross-shard)
Funcionamiento de Escalación Elástica
La sección anaranjada muestra el aplicativo (Punto 1), el cual por medio de las librerías cliente .NET “Elastic Escale” va a poder hacer la administración del mapeo de los Shard.
Esto permitirá registrar “Shards”, definir la llave o rangos, tener metadata actualizada del estado de los “Shards”.
Sobre esto, hay que tener en cuenta que el aplicativo guarda una copia cache del mapa de particiones para no consultar la base de datos “Shard Map Manager” y esta se convierta en un cuello de botella.
Cada vez que ocurre un cambio en las particiones, el cache anterior queda invalidado asegurando que obtendremos una copia actualizada.
La actividad de revisar el cache del mapa de particiones para el direccionamiento adecuado a él/los “Shards” (Punto 2) se denomina ruteo dependiendo de los datos (“DDR” Data Dependent Routing) ejemplificado a continuación:
Las consultas Multi-partición (“MSQ” Multi-Shard Queries) que se ve en el punto 3 de la gráfica de funcionamiento, ocurre cuando la consulta requiere de más (o todos los) shards. Bajo este escenario se realiza la misma consulta para cada partición involucrada y después se ensambla los resultados con un UNION ALL.
En el punto 4 de la gráfica de funcionamiento, se muestra que dependiendo las necesidades de distribución de los datos, se puede crear o fusionar particiones. Cuando esto ocurre, automáticamente se actualiza la base de datos que contiene el mapa de partición.
Más información:
Azure SQL Database Elastic Scale Overview
https://azure.microsoft.com/en-us/documentation/articles/sql-database-elastic-scale-introduction/
Azure SQL Database Elastic Scale
https://channel9.msdn.com/Shows/Data-Exposed/Azure-SQL-Database-Elastic-Scale