Azure SQL Database
En Azure tenemos diferentes opciones para disponer de un servicio de base de datos SQL Database, pero en este post me voy a centrar en el servicio PaaS (Platfom as a service) de Azure SQL Database, que incluye toda una serie de características de administración automáticas como las copias de seguridad o las actualizaciones, lo que nos ahorrará tiempo y problemas. Hay otras opciones con sus ventajas y desventajas, como las propias máquinas virtuales o las instancias administradas de SQL, que en según qué casos pueden llegar a ser necesarios, pero que en la gran mayoría de los casos no es así; al final del post las explicaré brevemente.
Configurar Azure SQL Database requiere detallar toda una serie de opciones, como con cualquier servicio de Azure; voy a centrarme en dos de los más importantes: el tipo de modelo de implementación, y el tipo de modelo de compra.
Modelo de implementación
El tipo de modelo de implementación permite elegir entre una base datos única y un grupo elástico: o sea, si solo vamos a trabajar con una base de datos, o aunque tengamos varias preferimos trabajar con ellas individualmente, la opción de base de datos única es la apropiada, puesto que será una base de datos aislada y totalmente administrada.
Tendremos un conjunto de recursos disponible solo para ella, y la administraremos a través de un “servidor lógico”. Podemos contratar tantos servicios de bases de datos únicas como requiramos.
Sin embargo, en muchas ocasiones nos encontraremos con que tenemos un conjunto de bases de datos, cada una con un uso distinto y no previsible: en estos casos contratar un grupo elástico puede ser la mejor opción ya que dispondremos de unos recursos que compartirán entre las diferentes bases de datos que tengamos en el grupo elástico, y se aprovecharán de esos recursos cuando lo requieran.
Siempre puede suceder que en algún momento haya un uso intensivo de más de una que provoque que esos recursos no sean suficientes y las respuestas puedan ser más lentas, pero en general siempre maximizaremos el ratio recursos/costes, y caso que esos momentos de uso intensivo no fueran solo ocasionales la facilidad que tenemos a la hora de modificar los recursos asignados nos permite hacer los cambios que requiramos.
Modelo de compra
El tipo de modelo de compra se refiere a cómo vamos a contratar la potencia de procesamiento que requiramos: hay dos opciones, que son el basado en núcleos virtuales, y el basado en DTU (Database Transaction Unit). Si elegimos el basado en núcleos virtuales deberemos seleccionar el tipo de hardware (o sea, la “generación” del hardware, con sus límites de proceso y memoria), la cantidad de núcleos virtuales que queremos aprovisionar, y el nivel de servicio (define generalmente la arquitectura de almacenamiento, los límites de espacio y de E/S y las opciones de disponibilidad y la recuperación ante desastres). Este modelo de compra en general proporciona mejores prestaciones y, consecuentemente, costes más elevados.
Por el contrario, el modelo basado en DTU (son la unidad en la que se mide el rendimiento de Azure SQL Database) implica unas cantidad máximas fijas de almacenamiento o de cantidad de bases de datos, aunque al igual que en el modelo de núcleos virtuales sí deberemos seleccionar el nivel de servicio que deseemos.
En cualquier caso la flexibilidad de Azure nos permite cambiar tanto el modelo de implementación, como el modelo de compra. Si una herramienta informática corporativa que utiliza una base de datos empieza a usarse en mayor medida y por tanto requiere mayores recursos, podemos ampliarlos tanto si su modelo de implementación es de base de datos única como de grupo elástico. Incluso si fuera el caso podríamos sacarla del grupo elástico y convertirla en base de datos única. Y al revés también, podemos incluir en un grupo elástico una base de datos única.
Otras opciones
Aunque no entraré en detalles, sí mencionaré opciones que tenemos para usar servicios de SQL Database en Azure más allá de los comentados:
- Instancia administrada: Azure SQL Managed Instance combina la mayor compatibilidad con la última versión del motor de base de datos de SQL Server y todas las ventajas de una plataforma como servicio totalmente administrada y permanente. Es la mejor opción para aquellos clientes que quieran migrar un gran número de aplicaciones desde un entorno local o de IaaS a un entorno en la nube de PaaS totalmente administrado, con el menor esfuerzo de migración posible
- SQL Server en Azure Virtual Machines: permite usar versiones completas de SQL Server en la nube sin tener que administrar todo el hardware local. Puede suceder que utilicemos una solución informática con ciertas peculiaridades que obliguen, o aconsejen, a utilizar una configuración muy concreta de SQL Server, y por tanto que la mejor solución no pase por Azure SQL Database, sino por una máquina virtual con SQL Server
Espero que este resumen os facilite la comprensión de las diferentes opciones que tenemos disponibles al respecto de los servicios SQL Database en Azure: tenéis la documentación oficial de Microsoft en https://docs.microsoft.com/es-es/azure/azure-sql/