Azure SQL Managed Instance (MI) es una plataforma para la gestión de bases de datos en la nube con un equilibrio perfecto entre la administración manual y delegada en el proveedor, pero es esencial comprender sus características y limitaciones para optimizar su rendimiento. Hoy vamos a hablar de la compresión de datos, de la que ya hablamos detenidamente en otro artículo, como estrategia para mitigar limitaciones relacionadas con los recursos de IO, RAM y CPU. En este artículo, exploraremos cómo la compresión de datos puede ayudar a superar estas limitaciones, proporcionando datos objetivos sobre las especificaciones de Azure MI y los precios (en la región de España Central a modo de ejemplo).
Características y limitaciones de Azure SQL Managed Instance
Lo primero que tenemos que tener claro es el terreno de juego en el que estamos, la nube es teóricamente escalable sin límite, sin embargo, tanto los proveedores como, sobre todo, nuestro bolsillo va a ser el principal limitante. Veamos qué es lo que nos ofrece Azure para el caso de las Managed Instance.
Niveles de servicio y recursos asignados:
Azure MI ofrece principalmente dos niveles de servicio el de uso general y el crítico. Además, dentro de estos niveles de servicio vamos a poder elegir tres tipos de hardware diferente. Parece un poco lioso, y realmente lo es, así que vamos a tratar de hacerlo fácil.
Lo primero que tenemos que conocer son los niveles de servicio que son:
- De uso general (General Purpose): Diseñado para cargas de trabajo empresariales comunes con requisitos de rendimiento moderados y alta disponibilidad.
- Crítico para la empresa (Business Critical): Orientado a aplicaciones de misión crítica que requieren alta velocidad de transacciones y baja latencia.
Estos niveles de servicio van a marcar los límites de recursos que podemos asignar a nuestra instancia, pero además de estos tenemos que tener en cuenta el tipo de hardware. Por ejemplo en el nivel de uso general el límite de CPUs que podemos asignar es de 80 cores para el hardware estándar y el serie premium pero solo hasta 64 cores en el hardware optimizado para memoria. Es el nivel crítico para la empresa el hardware estándar tendrá un máximo de 80 cores mientras que el hardware premium y el optimizado para memoria podrá tener hasta 128.
Compresión para salvar los límites de RAM para Azure MI
Una de las cosas curiosas de Azure SQL MI es que la asignación de recursos de memoria RAM no es seleccionable y depende directamente de la cantidad de núcleos virtuales que tengamos.
- Hardware de la serie estándar: 5,1 GB de RAM por vCore con un máximo de 480 Gb. Por ejemplo, 16 vCore = 81,6 GB de RAM.
- Hardware de la serie Premium: 7 GB de RAM por vCore con un máximo de 560 Gb. Por ejemplo, 16 vCore = 112 GB de RAM.
- Hardware optimizado para memoria: 13,6 GB de RAM por vCore con un máximo de 870,4 Gb. Por ejemplo, 16 vCore=217 GB de RAM.
Como podéis ver, la cantidad máxima de RAM es muy limitada y más cuando no nos dejamos el presupuesto de toda la empresa en núcleos de Azure MI. Por esta razón es fundamental habilitar la compresión en todas las tablas e índices de nuestras bases de datos. Cuantos más datos podamos cachear mejor, recordad que para que SQL tenga un rendimiento decente tiene que ser capaz de tener en memoria la información a la que se accede frecuentemente además de espacio suficiente para cachear planes de ejecución y demás operaciones que se hacen en memoria.
Almacenamiento en Azure MI
Ahora vamos con una de las cosas que menos me gustan de este modelo de dimensionamiento que tiene Azure MI y es que la capacidad de almacenamiento está limitada por la cantidad de núcleos adquirida. De esta manera, en el nivel de uso general con menos de 8 núcleos no puedes tener más de 2 Tb de datos, con menos de 16 núcleos no puedes tener más de 8 Tb de datos y para llegar hasta el máximo de 16 Tb de datos vas a necesitar 16 núcleos o más. Veamos esto en precios con el hardware estándar para que nos duela menos al ver los costes.
Propósito general:
- ¿Necesitas menos de 2 TB? Puedes dimensionar 4 núcleos, 1.013,99 € mensuales.
- ¿Necesitas más de 2 TB? Necesitas mínimo de 8 núcleos, 2.569,88 € mensuales.
- ¿Necesitas más de 8 TB? Necesitas mínimo de 16 núcleos, 5.143,85 € mensuales.
- ¿Necesitas más de 16 TB? Lo siento, no puedes tener esa cantidad. (Puedes tener más núcleos pagando más, pero esta lista se basa en los tamaños de disco).
Veamos también cómo va el almacenamiento en el nivel crítico para la empresa (esta vez en hardware premium que es más flexible):
- ¿Necesitas menos de 1 TB? Puedes dimensionar 4 núcleos virtuales, 2.614,23 € mensuales.
- ¿Necesitas más de 1 TB? Mínimo de 8 núcleos, 5.237,48 € mensuales.
- ¿Necesitas más de 2 TB? Mínimo de 16 núcleos, 10.483,97 € mensuales.
- ¿Necesitas más de 4 TB? Mínimo de 24 núcleos, 15.584,32 € mensuales.
- ¿Necesitas más de 5,5 TB? En España no se puede.
Os dejo ahora una imagen extraída de la documentación oficial sobre las limitaciones de espacio. Para el cálculo de precios podéis usar la calculadora oficial.
Velocidad de los discos
Si todo esto que hemos visto no es un problema para vosotros esperad porque ahora viene lo realmente “problemático” en Azure MI. La velocidad de estos discos, medida en IOPS (E/S por segundo), es realmente baja y, aunque va aumentando con el tamaño de los archivos, no llega a ser comparable a sistemas tradicionales On-Prem. Además de que escalar los ficheros nos va a implicar necesidades extra de tamaño y por tanto de cores y, si lo habéis adivinado, de más dinero todos los meses. Veamos esta otra imagen de la misma documentación que comentábamos antes:
Ahora os voy a dejar otra imagen de Kingston sobre las velocidades de sus discos actuales
Como veis, en el mejor de los casos, un archivo de Azure MI de más de 4 Tb tendría una velocidad de 250 Mib/s (Mebibits por segundo) o lo que es lo mismo 32,7 MB/s (Megabytes por segundo). Un SSD M2 NVME actual de cuatro canales nos está dando 8000.
Recuerda que para tener 4Tb (32,7 MB/s) en una instancia de nivel crítico para la empresa estamos hablando de más de 15.000 € al mes, eso sin contar con dimensionar también el fichero de log que, en este nivel de servicio y en España, ni podríamos llevarlo a este tamaño. En el nivel propósito general si podemos pero, estamos hablando de 5.100 € al mes para tener 8 Tb (4 para datos y 4 para log).
Nada más que decir.
Conclusión: Compresión para reducir las lecturas
Lo que os quería hacer ver con todo este texto que os he puesto hasta ahora es que en Azure MI las reglas del juego cambian y reducir las lecturas en disco y maximizar el tiempo que los datos permanecen en caché es clave para el rendimiento. Por este motivo necesitarás una buena política de indexación, comprimir los datos y, si es posible, eliminar todos los datos que ya no sean necesarios.
Si tenéis alguna duda o sugerencia, podéis dejarla en Twitter, por mail o dejarnos un mensaje en los comentarios. Y recuerda que también tenemos un grupo de Telegram y un canal de YouTube a los que te puede unir. ¡Hasta la próxima!
