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 modelos de arquitectura que se usan en Azure SQL Database:

  • De uso general/Estándar
  • Crítico para la empresa/Premium
  • Hiperescala

El nivel de servicio Hiperescala de Azure SQL Database es el nivel de servicio más reciente en el modelo de compra basado en núcleo virtual. Este nivel de servicio es un nivel altamente escalable de almacenamiento y de rendimiento de proceso que aprovecha la arquitectura de Azure para escalar horizontalmente el almacenamiento y los recursos de proceso para una base de datos de Azure SQL considerablemente más allá de los límites disponibles para los niveles de servicio Uso general y Crítico para la empresa.

Nota

  • 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 ver una comparación entre el modelo de compra basado en núcleo virtual y el modelo de compra basado en DTU, consulte Modelos de compra y recursos 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:

  • Compatibilidad con bases de datos de hasta 100 TB.
  • Copias de seguridad de base de datos rápidas (basadas en las instantáneas almacenadas en Azure Blob Storage) independientemente del tamaño sin efecto de la E/S en recursos de proceso.
  • Restauraciones rápidas de bases de datos (basadas en instantáneas de archivos) en minutos en lugar de horas o días (no del tamaño de la operación de datos).
  • 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.
  • 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.
  • 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.

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 cobrará solo la capacidad 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. Pueden crearse copias de seguridad de las bases de datos de hiperescala 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. 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 transacciones híbridas y procesamiento analítico (HTAP).

Importante

Los grupos elásticos no admiten el nivel de servicio Hiperescala.

Modelo de precios de Hiperescala

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:

    El precio de la unidad de proceso de Hiperescala es por réplica. El precio de la Ventaja híbrida de Azure se aplica automáticamente a las réplicas de alta disponibilidad y con nombre. Los usuarios pueden 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 una variedad de cargas de trabajo de escalado horizontal de lectura.

  • 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 100 TB y crece en incrementos de 10 GB.

Para más información sobre los precios de Hiperescala, consulte Precios de Azure SQL Database

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 y del tipo de almacenamiento, el rendimiento y el tamaño máximo de almacenamiento, tal como se describe en la tabla siguiente.

Uso general Hiperescala Crítico para la empresa
Más adecuado para Ofrece opciones de proceso y almacenamiento equilibradas adecuadas para un presupuesto limitado. La mayoría de las cargas de trabajo empresariales. Escalado automático del tamaño de almacenamiento hasta 100 TB, escalado de procesos vertical y horizontal rápido, restauración rápida de bases de datos. Aplicaciones de OLTP con una alta tasa de transacciones y latencia de E/S baja. Ofrece mayor resistencia a los errores y rapidez en las conmutaciones por error mediante varias réplicas actualizadas sincrónicamente.
Tamaño de proceso 2 a 128 núcleos virtuales 2 a 128 núcleos virtuales1 2 a 128 núcleos virtuales
Tipo de almacenamiento Almacenamiento remoto Premium (por instancia) Almacenamiento desacoplado con caché de SSD local (por instancia) Almacenamiento SSD local extremadamente rápido (por instancia)
Tamaño de almacenamiento1 5 GB – 4 TB Hasta 100 TB 5 GB – 4 TB
E/S 500 IOPS por núcleo virtual con 7000 IOPS como máximo Hiperescala es una arquitectura de varios niveles con almacenamiento en caché en varios niveles. Los IOPS efectivos dependen de la carga de trabajo. 5000 IOPS hasta un máximo de 200 000 IOPS
Disponibilidad 1 réplica, sin escalado horizontal de lectura, alta disponibilidad con redundancia de zona, sin caché local Varias réplicas, hasta 4 escalados horizontales de lectura, alta disponibilidad con redundancia de zona, caché local parcial 3 replicas, 1 escalado horizontal de lectura, alta disponibilidad con redundancia de zona, caché local completa
Copias de seguridad Una opción de almacenamiento de copia de seguridad con redundancia geográfica, con redundancia de zona o con redundancia local, retención de 1 a 35 días (valor predeterminado de 7 días) Una opción de almacenamiento de copia de seguridad con redundancia geográfica, con redundancia de zona o con redundancia local, retención de 1 a 35 días (valor predeterminado de 7 días) Una opción de almacenamiento de copia de seguridad con redundancia geográfica, con redundancia de zona o con redundancia local, retención de 1 a 35 días (valor predeterminado de 7 días)

1 Los grupos elásticos no se admiten en el nivel de servicio Hiperescala.

Nota:

La retención de copia de seguridad a corto plazo de entre 1 y 35 días para las bases de datos de Hiperescala está ahora en versión preliminar.

Recursos de proceso

Configuración de hardware CPU Memoria
Gen4 - Procesadores Intel® E5-2673 v3 (Haswell) de 2,4 GHz
- Aprovisionamiento de hasta 24 núcleos virtuales (físicos)
- 7 GB por núcleo virtual
- Aprovisionamiento de hasta 168 GB
Serie estándar (Gen5) Proceso aprovisionado
- Procesadores Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel® Xeon Platinum 8307C (Ice Lake)*, AMD EPYC 7763v (Milan)
- Aprovisionamiento de hasta 128 núcleos virtuales (Hyper-Threaded)

Proceso sin servidor
- Procesadores Intel® E5-2673 v4 (Broadwell) 2,3 GHz, Intel® SP-8160 (Skylake)*, Intel® 8272CL (Cascade Lake) 2,5 GHz*, Intel Xeon® Platinum 8307C (Ice Lake)*, AMD EPYC 7763v (Milan)
- Escalado vertical automático de hasta 40 núcleos virtuales (Hyper-Threaded)
Proceso aprovisionado
- 5,1 GB por núcleo virtual
- Aprovisionamiento de hasta 625 GB

Proceso sin servidor
- Escalado vertical automático de hasta 24 GB por núcleo virtual
- Escalado vertical automático de hasta 120 GB máx.
Serie prémium (versión preliminar) - Procesadores Intel® Xeon Platinum 8307C (Ice Lake), AMD EPYC 7763v (Milan) - 5,1 GB por núcleo virtual
- Aprovisionamiento de hasta 128 núcleos virtuales (Hyper-Threaded)
Serie premium optimizada para memoria (versión preliminar) - Procesadores Intel® Xeon Platinum 8307C (Ice Lake), AMD EPYC 7763v (Milan) - 10,2 GB por núcleo virtual
- Aprovisionamiento de hasta 80 núcleos virtuales (Hyper-Threaded)

* 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 8307C (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.

Importante

El hardware Gen4 se está retirando y no está disponible para implementaciones nuevas, como se anunció el 18 de diciembre de 2019. Los clientes que usan Gen4 para bases de datos Azure SQL, grupos elásticos o instancias administradas de SQL deben migrar al hardware disponible actualmente, como la serie estándar (Gen5), antes del 31 de enero de 2023.

Para obtener más información sobre la retirada del hardware Gen4 y la migración al hardware actual, consulte nuestra entrada de blog sobre la retirada de Gen4. Las bases de datos Gen4 existentes, los grupos elásticos y las instancias administradas de SQL se migrarán automáticamente al hardware de la serie estándar equivalente (Gen5).

El tiempo de inactividad causado por la migración automática será mínimo y similar al tiempo de inactividad durante las operaciones de escalado dentro del nivel de servicio seleccionado. Para evitar interrupciones no planeadas en las cargas de trabajo, migre de forma proactiva en el momento de su elección antes del 31 de enero de 2023.

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 ofrece la posibilidad de escalar fácilmente la capacidad de almacenamiento en la medida en que sea necesario (el objetivo inicial es de 100 TB), así como de escalar rápidamente los recursos de proceso.

El siguiente diagrama muestra la arquitectura de Hiperescala funcional:

arquitectura

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.

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. Consulte 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.

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 (es decir, un evento de mantenimiento), el sistema crea la nueva réplica principal antes de iniciar la 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 (es decir, un error de hardware en la réplica principal), el sistema usa una réplica del 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.

Para el contrato de nivel de servicio de Hiperescala, consulte Contrato de nivel de servicio para Azure SQL Database.

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. Dado que la arquitectura de Hiperescala usa la capa de almacenamiento para la copia de seguridad y restauración, la carga de procesamiento y el impacto en el rendimiento de las réplicas de proceso se reducen significativamente. 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.

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
Retención de copias de seguridad a corto plazo La retención de copia de seguridad a corto plazo de entre 1 y 35 días para las bases de datos de Hiperescala está ahora en versión preliminar. 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.
Retención de copia de seguridad a largo plazo La retención de copia de seguridad a largo plazo para las bases de datos de Hiperescala está ahora en versión preliminar.
El cambio del nivel de servicio de Hiperescala al nivel De uso general se admite directamente en escenarios limitados La migración desde Hiperescala permite a los clientes que han migrado recientemente un Azure SQL Database al nivel de servicio Hiperescala mover al nivel De uso general si Hiperescala no satisface sus necesidades. Aunque un cambio de nivel de servicio inicia la migración inversa, básicamente es un movimiento del tamaño de los datos entre diferentes arquitecturas. Las bases de datos creadas en el nivel de servicio Hiperescala no son válidas para la migración inversa. Más información sobre las limitaciones de la migración inversa.

En el caso de las bases de datos que no son válidas para la migración inversa, la única manera de migrar de Hiperescala a otro nivel de servicio es exportar o importar mediante un archivo bacpac u otras tecnologías de movimiento de datos (copia masiva, Azure Data Factory, Azure Databricks, SSIS, etc.). No se admite la exportación o importación de bacpac desde Azure Portal, desde PowerShell mediante New-AzSqlDatabaseExport o New-AzSqlDatabaseImport, desde la CLI de Azure con az sql db export y az sql db import ni desde la API de REST. Se admite la importación y exportación de bases de datos de Hiperescala (200 GB como máximo) mediante SSMS y SqlPackage versión 18.4 y posteriores. En el caso de las bases de datos de mayor tamaño, la importación y exportación de bacpac puede tardar mucho tiempo y producir errores por diversos motivos.
Grupos elásticos Los grupos elásticos no son compatibles actualmente con 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 deben cambiarse a tablas de disco.
Reducir base de datos Actualmente no se admite DBCC SHRINKDATABASE, DBCC SHRINKFILE o establecer AUTO_SHRINK en ON en el nivel de base de datos para las bases de datos de Hiperescala.
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 and DBCC CHECKFILEGROUP WITH TABLOCK may be used as a workaround. 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.

Pasos siguientes

Puede encontrar más información sobre Hiperescala en Azure SQL Database en los artículos siguientes: