Nivel de servicio Hiperescala
Se aplica a: 
Azure SQL Database
Azure SQL Database se basa en la arquitectura del Motor de base de datos de SQL Server que se ajusta al entorno en la nube, con el fin de garantizar una alta disponibilidad incluso en los casos de errores de la infraestructura. Hay tres opciones de nivel de servicio en el modelo de compra de núcleo virtual para Azure SQL Database:
- De uso general
- Crítico para la empresa
- Hiperescala
El nivel de servicio Hiperescala es adecuado para todos los tipos de carga de trabajo. Su arquitectura nativa de nube proporciona proceso y almacenamiento escalables de forma independiente para admitir la mayor variedad de aplicaciones tradicionales y modernas. Los recursos de proceso y almacenamiento en Hiperescala superan considerablemente los disponibles en los niveles De uso general y Crítico para la empresa.
Para más información acerca de los niveles de servicios Uso general y Crítico para la empresa en el modelo de compra basado en núcleo virtual, consulte los niveles de servicio Uso general y Crítico para la empresa. Para obtener una comparación entre el modelo de compra basado en núcleo virtual y el modelo de compra basado en DTU, vea Comparación de los modelos de compra basados en núcleo virtual y DTU de Azure SQL Database.
Actualmente, el nivel de servicio Hiperescala solo está disponible para Azure SQL Database, pero no para Azure SQL Managed Instance.
¿Cuáles son las funcionalidades de Hiperescala?
El nivel de servicio Hiperescala en Azure SQL Database proporciona las siguientes funcionalidades adicionales:
- Rápido escalado vertical: en tiempo constante, puede escalar verticalmente los recursos de proceso para dar cabida a cargas de trabajo pesadas cuando sea necesario y, después, reducir verticalmente los recursos de proceso cuando no sean necesarios.
- Rápido escalado horizontal: puede aprovisionar una o varias réplicas de solo lectura para la descarga de la carga de trabajo de lectura y para su uso como esperas activas.
- Escalado vertical, reducción vertical y facturación automáticos para el proceso en función del uso con proceso sin servidor.
- Precio y rendimiento optimizados para un grupo de bases de datos de Hiperescala con demandas de recursos variables y grupos elásticos.
- Almacenamiento de escalado automático con compatibilidad con hasta 128 TB de base de datos o tamaño de grupo elástico de 100 TB.
- Mayor rendimiento general debido a una mayor capacidad de proceso de los registros de transacciones y tiempos más rápidos de confirmación de estas, independientemente de los volúmenes de datos.
- Copias de seguridad de base de datos rápidas (basadas en instantáneas de archivos) independientemente del tamaño sin efecto de la E/S en recursos de proceso.
- Copias o restauraciones rápidas de base de datos (basadas en instantáneas de archivos) en minutos en lugar de horas o días.
El nivel de servicio Hiperescala elimina muchos de los límites prácticos que tradicionalmente se ven en las bases de datos en la nube. Donde la mayoría de las otras bases de datos están limitados por los recursos disponibles en un único nodo, las bases de datos en el nivel de servicio Hiperescala no tienen límites de este tipo. Con su arquitectura de almacenamiento flexible, el almacenamiento crece a medida que sea necesario. De hecho, las bases de datos de Hiperescala no se crean con un tamaño máximo definido. Una base de datos de Hiperescala aumenta según sea necesario, y se le cobra solo la capacidad de almacenamiento que use. Para cargas de trabajo de lectura intensiva, el nivel de servicio Hiperescala proporciona rápida escalabilidad horizontal mediante el aprovisionamiento de réplicas adicionales según sea necesario para descargar las cargas de trabajo de lectura.
Además, el tiempo necesario para crear copias de seguridad de bases de datos o para escalar o reducir verticalmente ya no está ligado al volumen de los datos en la base de datos. Las copias de seguridad de las bases de datos de Hiperescala se realizan de manera prácticamente instantánea. También puede escalar o reducir verticalmente una base de datos de decenas de terabytes en cuestión de minutos en el nivel de proceso aprovisionado o usar sin servidor para escalar el proceso automáticamente. Esta funcionalidad le libra de la preocupación de estar atado por las opciones de la configuración inicial.
Para más información sobre los tamaños de proceso para el nivel de servicio Hiperescala, consulte Características de los niveles de servicios.
Quién debe tener en cuenta el nivel de servicio Hiperescala
El nivel de servicio Hiperescala esta destinado para todos los clientes que requieren un mayor rendimiento y disponibilidad, copias de seguridad y restauración rápidas o almacenamiento rápido y escalabilidad de procesos. Entre ellos se incluyen clientes que se trasladan a la nube para modernizar sus aplicaciones y clientes que ya usan otros niveles de servicio en Azure SQL Database. El nivel de servicio Hiperescala admite una amplia gama de cargas de trabajo de base de datos, desde OLTP puro hasta análisis puros. Está optimizado para cargas de trabajo OLTP y de procesamiento híbrido transaccional y analítico (HTAP).
Modelo de precios de Hiperescala
Nota:
¡Ya están aquí los precios simplificados para Hiperescala de Azure SQL Database! Consulta el anuncio del nuevo plan de tarifa para el anuncio de Hiperescala de Azure SQL Database y, para más información sobre los cambios de precios, consulta Hiperescala de Azure SQL Database: precios más bajos y simplificados.
El nivel de servicio Hiperescala solo está disponible en el modelo de núcleo virtual. Para alinearse con la nueva arquitectura, el modelo de precios es ligeramente diferente de los niveles de servicio Se uso general o Crítico para la empresa:
Proceso aprovisionado:
El precio de la unidad de proceso de Hiperescala es por réplica. Los usuarios podrían ajustar el número total de réplicas secundarias de alta disponibilidad de 0 a 4, según los requisitos de disponibilidad y escalabilidad, y crear hasta 30 réplicas con nombre para admitir varias cargas de trabajo de escalado horizontal de lectura.
Proceso sin servidor:
La facturación de proceso sin servidor se basa en el uso. Para más información, vea Nivel de proceso sin servidor de Azure SQL Database.
Almacenamiento:
No es necesario especificar el tamaño máximo de datos al configurar una base de datos Hiperescala. En el nivel Hiperescala, se le cobra por el almacenamiento de su base de datos según la asignación real. El almacenamiento se asigna automáticamente entre 10 GB y 128 TB y crece en incrementos de 10 GB según sea necesario.
Para obtener más información sobre los precios de Hiperescala, consulte Precios de Azure SQL Database.
Arquitectura de funciones distribuidas
Hiperescala separa el motor de procesamiento de consultas de los componentes que proporcionan almacenamiento a largo plazo y durabilidad de los datos. Esta arquitectura le permite escalar sin problemas la capacidad de almacenamiento en la medida en que sea necesario (hasta 128 TB) y la capacidad de escalar rápidamente los recursos de proceso.
El siguiente diagrama muestra la arquitectura de Hiperescala funcional:
Más información sobre la arquitectura de funciones distribuidas de Hiperescala.
Ventajas de escala y rendimiento
Con la capacidad de aumentar o disminuir rápidamente los nodos de ejecución adicionales de solo lectura, la arquitectura de Hiperescala permite obtener importantes funcionalidades de escalado de lectura y también puede liberar el nodo de ejecución principal para atender más solicitudes de escritura. Además, los nodos de ejecución se pueden escalar o reducir verticalmente rápidamente debido a la arquitectura de almacenamiento compartido de la arquitectura de Hiperescala. Los nodos de proceso de solo lectura en Hiperescala también están disponibles en el nivel de proceso sin servidor, que escala automáticamente el proceso en función de la demanda de cargas de trabajo.
Alta disponibilidad de la base de datos en Hiperescala
Como en todos los demás niveles de servicio, Hiperescala garantiza la durabilidad de los datos para las transacciones confirmadas, independientemente de la disponibilidad de la réplica de proceso. El grado de tiempo de inactividad debido a que la réplica principal no esté disponible depende del tipo de conmutación por error (planeada frente a no planeada), de si la redundancia de zona está configurada y de la presencia de al menos una réplica de alta disponibilidad. En una conmutación por error planeada (como un evento de mantenimiento), el sistema crea la réplica principal antes de iniciar una conmutación por error, o bien usa una réplica de alta disponibilidad existente como destino de la conmutación por error. En una conmutación por error no planeada (como un error de hardware en la réplica principal), el sistema usa una réplica de alta disponibilidad como destino de la conmutación por error, si existe, o crea una réplica principal a partir del grupo de capacidad de proceso disponible. En el último caso, la duración del tiempo de inactividad es mayor debido a pasos adicionales necesarios para crear la nueva réplica principal.
Puede elegir una ventana de mantenimiento que le permita hacer eventos de mantenimiento de alto impacto predecibles y menos perjudiciales para la carga de trabajo.
Para el contrato de nivel de servicio de Hiperescala, consulte Contrato de nivel de servicio para Azure SQL Database.
Grupo de búferes, extensión del grupo de búferes resistente y preparación continua
En Hiperescala de Base de datos de Azure, hay una separación distinta entre proceso y almacenamiento. El almacenamiento contiene todas las páginas de base de datos de una base de datos y se puede asignar a través de varias máquinas a medida que crece la base de datos. Sin embargo, el nodo de proceso solo almacena en caché lo que se usa recientemente. Las páginas más activas del proceso se mantienen en memoria en una estructura denominada grupo de búferes (BP). También se almacena en la SSD local, la extensión del grupo de búferes resistente (RBPEX), por lo que los datos se pueden recuperar más rápido en caso de que se reinicie el proceso de proceso.
En un sistema en la nube, el proceso puede moverse a diferentes máquinas según sea necesario. La capa de proceso puede tener varias réplicas. Uno es principal y recibe todas las actualizaciones, mientras que otras son réplicas secundarias. En caso de un error principal, una de las réplicas secundarias de alta disponibilidad se puede promover rápidamente a principal en un proceso denominado conmutación por error. Es posible que la réplica secundaria no tenga una memoria caché en su BP y RBPEX optimizada para la carga de trabajo principal.
La preparación continua es un proceso que recopila información sobre qué páginas son las más activas en todas las réplicas de proceso. Esa información se agrega y las réplicas secundarias de alta disponibilidad usan la lista de páginas más frecuentes que corresponden a la carga de trabajo típica del cliente. Esto rellena tanto BP como RBPEX con las páginas más activas, continuamente, para mantenerse al día con los cambios en la carga de trabajo del cliente.
Sin preparación continua, BP y RBPEX no heredan nuevas réplicas de alta disponibilidad y solo se reconstruyen durante la carga de trabajo del usuario. La preparación continua ahorra tiempo y evita un rendimiento incoherente, ya que no hay ninguna espera antes de que las memorias caché se vuelvan a hidratar completamente. Con la preparación continua, las nuevas réplicas secundarias de alta disponibilidad comenzarán inmediatamente a preparar su BP y RBPEX. Esto ayudará a mantener el rendimiento de forma más coherente a medida que se produzcan conmutaciones por error.
La preparación continua funciona de ambas maneras: las réplicas secundarias de alta disponibilidad almacenarán en caché las páginas que se usan en la réplica principal y las páginas principales almacenarán en caché las páginas con la carga de trabajo de las réplicas secundarias.
Nota:
La preparación continua se encuentra actualmente en una versión preliminar controlada y no está disponible para las bases de datos sin servidor. Para obtener más información y participar en la preparación continua, consulte Blog: Mejoras de hiperescala de noviembre de 2024.
Copia de seguridad y restauración
Las operaciones de copia de seguridad y restauración de bases de datos de Hiperescala se basan en instantáneas de archivos. Esto permite que estas operaciones sean prácticamente instantáneas. Como la arquitectura de Hiperescala usa la capa de almacenamiento para la copia de seguridad y la restauración, la carga de procesamiento y el impacto en el rendimiento de las réplicas de proceso se reducen. Obtenga más información en Copias de seguridad de Hiperescala y redundancia de almacenamiento.
Recuperación ante desastres para bases de datos Hiperescala
Si necesita restaurar una base de datos Hiperescala de Azure SQL Database en una región distinta a donde se hospeda actualmente —como parte de una operación de recuperación ante desastres, una exploración en profundidad, una reubicación o cualquier otro motivo—, el método principal es realizar una restauración geográfica de la base de datos. La restauración geográfica solo está disponible cuando se ha elegido el almacenamiento con redundancia geográfica (RA-GRS) para la redundancia del almacenamiento.
Learn more in Restauración de una base de datos de Hiperescala en una región diferente.
Comparación de los límites de recursos
Los niveles de servicio basados en núcleos virtuales se diferencian en función de la disponibilidad de la base de datos, el tipo de almacenamiento, el rendimiento y el tamaño máximo de almacenamiento. Estas diferencias se describen en la siguiente tabla:
| ㅤ | Uso general | Crítico para la empresa | Hiperescala |
|---|---|---|---|
| Más adecuado para | Ofrece opciones de proceso y almacenamiento equilibradas adecuadas para un presupuesto limitado. | Aplicaciones de OLTP con una alta tasa de transacciones y latencia de E/S baja. Ofrece alta resistencia a los errores y conmutaciones por error rápidas mediante varias réplicas de espera activa. | La mayor variedad de cargas de trabajo. Escalado automático del tamaño de almacenamiento hasta 128 TB, escalado de proceso vertical y horizontal rápido, restauración rápida de bases de datos. |
| Tamaño de proceso | 2 a 128 núcleos virtuales | 2 a 128 núcleos virtuales | 2 a 128 núcleos virtuales |
| Tipo de almacenamiento | Almacenamiento remoto Premium (por instancia) | Almacenamiento SSD local extremadamente rápido (por instancia) | Almacenamiento desacoplado con caché de SSD local (por réplica de proceso) |
| Tamaño de almacenamiento | 1 GB a 4 TB | 1 GB a 4 TB | 10 GB a 128 TB |
| E/S | 320 IOPS por núcleo virtual con 16 000 IOPS como máximo | 4000 IOPS por núcleo virtual con 327 680 IOPS como máximo | 327 680 IOPS de SSD local máximo Hiperescala es una arquitectura de varios niveles con almacenamiento en caché en varios niveles. Las operaciones IOPS efectivas dependen de la carga de trabajo. |
| Memoria/núcleo virtual | 5,1 GB | 5,1 GB | 5,1 GB o 10,2 GB |
| Disponibilidad | Una réplica, sin escalado horizontal de lectura, alta disponibilidad con redundancia de zona | Tres réplicas, un escalado horizontal de lectura, alta disponibilidad con redundancia de zona | Varias réplicas, hasta cuatro escalados horizontales de lectura, alta disponibilidad con redundancia de zona |
| Copias de seguridad | Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención que oscila entre 1 y 35 días (7 días de manera predeterminada), con hasta 10 años de retención a largo plazo disponible |
Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención que oscila entre 1 y 35 días (7 días de manera predeterminada), con hasta 10 años de retención a largo plazo disponible |
Una opción de almacenamiento con redundancia local (LRS), almacenamiento con redundancia de zona (ZRS) o almacenamiento con redundancia geográfica (GRS) Retención que oscila entre 1 y 35 días (7 días de manera predeterminada), con hasta 10 años de retención a largo plazo disponible |
| Precios y facturación | El núcleo virtual, el almacenamiento reservado y el almacenamiento de copia de seguridad se cobran. No se cobran IOPS. |
El núcleo virtual, el almacenamiento reservado y el almacenamiento de copia de seguridad se cobran. No se cobran IOPS. |
Se cobran el núcleo virtual de cada réplica, el almacenamiento de datos asignados y el almacenamiento de copia de seguridad. No se cobran IOPS. |
| Modelos de descuento1 | Instancias reservadas Ventaja híbrida de Azure2 Suscripciones a ofertas de Desarrollo/pruebas de Enterprise y de pago por uso |
Instancias reservadas Ventaja híbrida de Azure2 Suscripciones a ofertas de Desarrollo/pruebas de Enterprise y de pago por uso |
Instancias reservadas Ventaja híbrida de Azure2 Suscripciones a ofertas de Desarrollo/pruebas de Enterprise y de pago por uso |
1 Los precios simplificados para Hiperescala de SQL Database comenzaron en diciembre de 2023. Revise el blog de precios de Hiperescala para más información.
2 A partir de diciembre de 2023, Ventaja híbrida de Azure no está disponible para nuevas bases de datos de Hiperescala o en suscripciones de desarrollo y pruebas. Las bases de datos únicas de Hiperescala existentes con proceso aprovisionado pueden seguir usando Ventaja híbrida de Azure para ahorrar en costos de proceso hasta diciembre de 2026. Para obtener más información, revise el blog de precios de Hiperescala.
Recursos de proceso
| Configuración de hardware | CPU | Memoria |
|---|---|---|
| Serie estándar (Gen5) | Proceso aprovisionado - Procesadores Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) - Aprovisionamiento de hasta 80 núcleos virtuales (Hyper-Threaded) Proceso sin servidor - Procesadores Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)1, Intel® 8272CL (Cascade Lake) 2,5 GHz1, Intel® Xeon® Platinum 8370C (Ice Lake)1, AMD EPYC 7763v (Milan) - Escalabilidad automática de hasta 80 núcleos virtuales (Hyper-Threaded). - La proporción de memoria a núcleo virtual se adapta dinámicamente al uso de memoria y CPU en función de la demanda de la carga de trabajo y puede llegar a un máximo de 24 GB por núcleo virtual. Por ejemplo, en un momento dado, una carga de trabajo puede usar y facturarse por 240 GB de memoria y tan solo 10 núcleos virtuales. |
Proceso aprovisionado - 5,1 GB por núcleo virtual - Aprovisionamiento de hasta 625 GB Proceso sin servidor - Escalabilidad automática de hasta 24 GB por núcleo virtual. - Escalabilidad automática vertical de hasta 240 GB máx. |
| Serie Premium | - Procesadores Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Aprovisionamiento de hasta 128 núcleos virtuales (Hyper-Threaded) |
- 5,1 GB por núcleo virtual |
| Serie Premium optimizada para memoria | - Procesadores Intel® Xeon® Platinum 8370C (Ice Lake), AMD EPYC 7763v (Milan) - Aprovisionamiento de hasta 80 núcleos virtuales (Hyper-Threaded) |
- 10,2 GB por núcleo virtual |
1 En la vista de administración dinámica sys.dm_user_db_resource_governance, la generación de hardware para bases de datos que usan procesadores Intel® SP-8160 (Skylake) aparece como Gen6, la generación de hardware para bases de datos que usan procesadores Intel® 8272CL (Cascade Lake) aparece como Gen7 y la generación de hardware para bases de datos que usan procesadores Intel® Xeon® Platinum 8370C (Ice Lake) o AMD® EPYC® 7763v (Milan) aparece como Gen8. Para una configuración de hardware y tamaño de proceso determinada, los límites de recursos son los mismos independientemente del tipo de CPU. Para obtener más información, consulte los límites de recursos de bases de datos únicas y grupos elásticos.
Sin servidor solo se admite en hardware de la serie estándar (Gen5).
Creación y administración de bases de datos de Hiperescala
Puede crear y administrar bases de datos de Hiperescala mediante Azure Portal, Transact-SQL, PowerShell y la CLI de Azure. Para más información, vea Inicio rápido: Creación de una base de datos de Hiperescala.
| Operación | Detalles | Más información |
|---|---|---|
| Creación de una base de datos de Hiperescala | Las bases de datos de Hiperescala solo están disponibles cuando se usa el modelo de compra basado en núcleo virtual. | Busque ejemplos para crear una base de datos de Hiperescala en Inicio rápido: Creación de una base de datos de Hiperescala en Azure SQL Database. |
| Actualización de una base de datos existente a Hiperescala | La migración de una base de datos de Azure SQL Database existente al nivel Hiperescala tiene el tamaño de una operación de datos. | Más información sobre cómo migrar una base de datos existente a Hiperescala. |
| Migración inversa de una base de datos de Hiperescala al nivel de servicio De uso general | Si ha migrado previamente una base de datos existente de Azure SQL Database al nivel de servicio Hiperescala, puede revertir la migración de una base de datos de Hiperescala al nivel de servicio De uso general en un plazo de 45 días a partir de la migración original a Hiperescala. Si quiere migrar la base de datos a otro nivel de servicio, como Crítico para la empresa, primero realice la migración inversa al nivel de servicio De uso general y, luego, cambie el nivel de servicio. |
Más información sobre cómo revertir la migración desde Hiperescala, incluidas las limitaciones de la migración inversa. |
Reducir
Las operaciones de reducción de bases de datos y archivos se encuentran actualmente en versión preliminar para Azure SQL Database Hyperscale. Para obtener más información sobre la versión preliminar, consulte Reducción para Azure SQL Database Hyperscale.
Restricciones conocidas
Estas son las limitaciones actuales del nivel de servicio Hiperescala. Estamos trabajando activamente para eliminar tantas limitaciones como sea posible.
| Incidencia | Descripción |
|---|---|
| La reducción se bloquea cuando el TDE está deshabilitado | Actualmente, las operaciones de reducción de archivos y bases de datos no se admiten cuando el Cifrado de datos transparente (TDE) está deshabilitado en Hiperescala de Azure SQL Database. |
| Restauración de la base de datos desde otros niveles de servicio | No se puede restaurar una base de datos de Hiperescala en una base de datos que no sea de Hiperescala, ni se puede restaurar una base de datos que no sea de Hiperescala en una base de datos de Hiperescala. En el caso de las bases de datos migradas a Hiperescala desde otros niveles de servicio de Azure SQL Database, se conservan copias de seguridad previas a la migración durante el período de retención de copias de seguridad de la base de datos de origen, incluidas las directivas de retención a largo plazo. Se admite la restauración mediante la línea de comandos de una copia de seguridad previa a la migración dentro del período de retención de copia de seguridad de la base de datos. Puede restaurar estas copias de seguridad a cualquier nivel de servicio que no sea de Hiperescala. |
| Migración de bases de datos con objetos OLTP en memoria | Hiperescala admite un subconjunto de objetos OLTP en memoria, incluidos los tipos de tablas optimizadas para memoria, las variables de tablas y los módulos compilados de forma nativa. Sin embargo, cuando hay presente cualquier objeto OLTP en memoria en la base de datos que se está migrando, no se admite la migración desde los niveles de servicio Premium y Crítico para la empresa a Hiperescala. Para migrar este tipo de base de datos a Hiperescala, se deben quitar todos los objetos OLTP en memoria y sus dependencias. Después de migrar la base de datos, estos objetos se pueden volver a crear. En este momento no se admiten tablas optimizadas para memoria, duraderas y no duraderas, en Hiperescala, y se deben cambiar a tablas de disco. |
| Comprobación de la integridad de la base de datos | DBCC CHECKDB no se admite actualmente con las bases de datos de Hiperescala. DBCC CHECKTABLE ('TableName') WITH TABLOCK y DBCC CHECKFILEGROUP WITH TABLOCK podrían utilizarse como una solución alternativa. Consulte Integridad de datos en Azure SQL Database para más información sobre la administración de esta en Azure SQL Database. |
| Trabajos elásticos | No se admite el uso de una base de datos de Hiperescala como base de datos de trabajo. Sin embargo, los trabajos elásticos pueden dirigirse a bases de datos de Hiperescala, de la misma manera que cualquier otra base de datos de Azure SQL Database. |
| Sincronización de datos | No se admite el uso de una base de datos de Hiperescala como base de datos central o de metadatos de sincronización. Sin embargo, una base de datos de Hiperescala puede ser una base de datos miembro en una topología de Data Sync. |
| Hardware de la serie Premium del nivel de servicio Hiperescala | La serie prémium y el hardware de la serie prémium optimizado para memoria no admiten actualmente el nivel de proceso sin servidor. |
| Disponibilidad regional | El hardware de las series prémium y prémium optimizado para memoria del nivel de servicio de Hiperescala está disponible en regiones limitadas de Azure. Para obtener una lista, consulte Disponibilidad de la serie Premium de Hiperescala. |
Contenido relacionado
- Preguntas más frecuentes sobre Hiperescala
- Comparación de los modelos de compra basados en núcleos virtuales y DTU de Azure SQL Database
- Administración de recursos en Azure SQL Database
- Límites de recursos para bases de datos únicas que utilizan el modelo de compra en núcleos virtuales
- Comparación de características: Azure SQL Database e Instancia administrada de Azure SQL
- Arquitectura de funciones distribuidas de Hiperescala
- Administración de una base de datos de Hiperescala