Azure SQL Database y Azure SQL Managed Instance permiten escalar de forma dinámica recursos a la base de datos con un tiempo de inactividad mínimo.

  • Artículo

Se aplica a:Azure SQL DatabaseAzure SQL Managed Instance

Azure SQL Database y Azure SQL Managed Instance le permiten agregar dinámicamente más recursos a su base de datos con un mínimo tiempo de inactividad; sin embargo, hay un breve período de cambio donde se pierde la conectividad a la base de datos, lo que se puede mitigar con la lógica de reintento.

Información general

Cuando la demanda de una aplicación aumenta de unos cuantos dispositivos y clientes a millones, Azure SQL Database y SQL Managed Instance se escalan sobre la marcha con un tiempo de inactividad mínimo. La escalabilidad es una de las características más importantes de plataforma como servicio (PaaS) que permite agregar de forma dinámica más recursos al servicio cuando sea necesario. Azure SQL Database permite cambiar fácilmente los recursos (potencia de CPU, memoria, almacenamiento y rendimiento de E/S) asignados a las bases de datos.

Puede mitigar problemas de rendimiento debidos al aumento del uso de la aplicación que no se pueden resolver mediante métodos de indexación o reescritura de consultas. Agregar más recursos permite reaccionar rápidamente cuando la base de datos alcanza los límites de recursos actuales y se necesita más capacidad para controlar la carga de trabajo entrante. Azure SQL Database también permite reducir verticalmente los recursos cuando no se necesitan para reducir el costo.

No es necesario preocuparse de comprar hardware ni cambiar la infraestructura subyacente. El escalado de una base de datos se puede realizar fácilmente a través de Azure Portal mediante un control deslizante.

Scale database performance

Azure SQL Database ofrece el modelo de compra basado en DTU y el modelo de compra basado en núcleo virtual, mientras que Instancia administrada de Azure SQL ofrece solo el modelo de compra basado en núcleo virtual.

  • El modelo de compra basado en DTU ofrece una combinación de recursos de proceso, memoria y E/S en tres niveles de servicio para admitir cargas de trabajo de base de datos de ligeras a pesadas: Básico, Estándar y Premium. Los niveles de rendimiento de cada nivel ofrecen una mezcla diferente de estos recursos, a los que puede agregar recursos de almacenamiento adicionales.
  • El modelo de compra basado en núcleo virtual le permite elegir el número de núcleos virtuales, la cantidad de memoria y la cantidad y velocidad del almacenamiento. Este modelo de compra ofrece tres niveles de servicio: Uso general, Crítico para la empresa e Hiperescala.

El nivel de servicio, nivel de proceso y límites de recursos de una base de datos, un grupo elástico o una instancia administrada se pueden cambiar en cualquier momento. Por ejemplo, la primera aplicación se puede compilar en una base de datos mediante el nivel de proceso sin servidor y, después, cambiar el nivel de servicio manualmente o mediante programación en cualquier momento, al nivel de proceso proporcionado, para adecuarla a las necesidades de su solución.

Nota

Las excepciones importantes en las que no se puede cambiar el nivel de servicio de una base de datos son:

  • Las bases de datos que usan características que solo están disponibles en los niveles de servicio Crítico para la empresa o Premium, no se pueden cambiar para usar el nivel de servicio De uso general o estándar. Actualmente, la única característica de este tipo es OLTP en memoria.
  • Las bases de datos creadas originalmente en el nivel de servicio Hiperescala no se pueden migrar a otros niveles de servicio. Si migra una base de datos existente en Azure SQL Database al nivel de servicio Hiperescala, puede revertir la migración al nivel de servicio De uso general en un plazo de 45 días a partir de la migración original a Hiperescala. Si desea migrar la base de datos a otro nivel de servicio, como Crítico para la empresa, primero realice una migración inversa al nivel de servicio De uso general y, a continuación, realice una migración adicional. Más información en Migración inversa desde Hiperescala (versión preliminar).

Puede ajustar los recursos asignados a la base de datos cambiando el objetivo de servicio o escalando para satisfacer las demandas de la carga de trabajo. Esto también le permite pagar solo por los recursos que necesita, cuando los necesite. Consulte la nota sobre el posible impacto que podría tener una operación de escalado en una aplicación.

Azure SQL Database ofrece la posibilidad de escalar dinámicamente las bases de datos:

  • Con una base de datos única, se pueden usar los modelos de DTU o núcleo virtual para definir la cantidad máxima de recursos que se asignarán a cada base de datos.
  • Los grupos elásticos permiten definir el límite máximo de recursos por grupo de bases de datos en el grupo.

Instancia administrada de Azure SQL permite escalar también:

  • SQL Managed Instance usa el modo de núcleos virtuales y le permite definir el máximo de núcleos de CPU y el máximo de almacenamiento asignado a la instancia. Todas las bases de datos dentro de la instancia administrada comparten los recursos asignados a la instancia.

Sugerencia

El escalado dinámico permite a los clientes cambiar la asignación de recursos manualmente o mediante programación. La funcionalidad de escalado dinámico está disponible para todos los recursos de Azure SQL Database y Azure SQL Managed Instance.

Además de admitir el escalado dinámico, el nivel Sin servidor de Azure SQL Database admite el escalado automático. Las bases de datos del nivel Sin servidor escalan los recursos automáticamente dentro de un intervalo especificado por el cliente, en función de la demanda de cargas de trabajo. No se requiere ninguna acción del cliente para escalar la base de datos.

Impacto de las operaciones de escalado o reducción verticales

Si se inicia la acción de escalado o reducción vertical en cualquiera de los tipos que se han mencionado, se reiniciará el proceso del motor de base de datos y se moverá a otra máquina virtual si es necesario. El cambio del proceso del motor de base de datos a una nueva máquina virtual es un proceso en línea durante el cual puede continuar usando el servicio de Azure SQL Database existente. Una vez que el motor de base de datos de destino esté listo para procesar las consultas, se finalizarán las conexiones abiertas al motor de base de datos actual y se revertirán las transacciones no confirmadas. Se realizarán nuevas conexiones al motor de base de datos de destino.

Nota

No se recomienda escalar la instancia administrada si se está ejecutando una transacción de larga duración, como la importación de datos, los trabajos de procesamiento de datos o la regeneración de índices, o si tiene una conexión activa en la instancia. Para evitar que el escalado tarde en completarse más tiempo que de costumbre, debe escalar la instancia una vez finalizadas todas las operaciones de ejecución prolongada.

Nota

Puede esperar una pequeña interrupción de la conexión cuando el proceso de escalado o reducción vertical haya terminado. Si ha implementado la lógica de reintentos para errores transitorios estándar, no notará la conmutación por error.

Métodos de escala alternativos

El escalado de recursos es la manera más fácil y eficaz de mejorar el rendimiento de una base de datos sin cambiar su código ni el de la aplicación. En algunos casos, es posible que ni siquiera los más altos niveles de servicio, tamaños de proceso y optimizaciones de rendimiento puedan controlar la carga de trabajo de forma correcta y rentable. En esos casos dispone de estas otras opciones para escalar la base de datos:

  • Escalado horizontal de lectura es una característica disponible en la que se obtiene una réplica de solo lectura de los datos en la que se pueden ejecutar exigentes consultas de solo lectura, como por ejemplo informes. Una réplica de solo lectura controlará la carga de trabajo de solo lectura sin que el uso de los recursos en la base de datos principal se vea afectado.
  • Particionamiento de base de datos es un conjunto de técnicas que permite dividir los datos en varias bases de datos y escalarlas por separado.

Pasos siguientes