Arquitectura de funciones distribuidas de Hiperescala
Se aplica a: 
Azure SQL Database
El nivel de servicio Hiperescala utiliza una arquitectura con niveles de almacenamiento y proceso altamente escalables y separados. En este artículo se describen los componentes que permiten a los clientes escalar rápidamente las bases de datos de Hiperescala, a la vez que se benefician de copias de seguridad casi instantáneas y del registro de transacciones altamente escalable.
Sugerencia
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.
Introducción a la arquitectura de Hiperescala
Los motores de base de datos tradicionales centralizan las funciones de administración de datos en un único proceso: incluso las llamadas bases de datos distribuidas en producción tienen actualmente varias copias de un motor de datos monolítico.
Las bases de datos de Hiperescala siguen un enfoque diferente. Hiperescala separa el motor de procesamiento de consultas, donde la semántica de los distintos motores de datos diverge, de los componentes que proporcionan el almacenamiento a largo plazo y la durabilidad de los datos. De este modo, la capacidad de almacenamiento se puede escalar horizontalmente con facilidad todo lo que se necesite, hasta 128 TB para una única base de datos de Hiperescala.
Toda la comunicación de red entre los componentes de Hiperescala usa la infraestructura de red de Azure con redundancia integrada.
Las réplicas secundarias de alta disponibilidad y las réplicas con nombre son nodos de proceso opcionales que se pueden agregar a petición. Ambas comparten los mismos componentes de almacenamiento, por lo que no se requiere ninguna copia de datos para poner en marcha una nueva réplica. Se puede agregar una réplica secundaria geográfica a petición en la misma región de Azure o en una diferente. Para la protección y redundancia de datos, las réplicas secundarias geográficas tienen componentes de almacenamiento independientes de los usados por la réplica principal.
El siguiente diagrama muestra la arquitectura de Hiperescala funcional:
Una base de datos de Hiperescala contiene los siguientes tipos de componentes: nodos de proceso, servidores de páginas, el servicio de registro y Azure Storage.
Proceso
El nodo de ejecución es la ubicación en la que reside el motor relacional. Es donde se produce el procesamiento de lenguajes, consultas y transacciones. Todas las interacciones de usuario con una base de datos de Hiperescala se producen a través de estos nodos de ejecución. Los nodos de proceso se pueden configurar para usar procesos sin servidor o aprovisionados.
Los nodos de proceso tienen cachés locales basadas en SSD denominadas extensión del grupo de búferes resistentes (caché de datos de RBPEX). La caché de datos de RBPEX es una caché de datos inteligente de baja latencia que minimiza la necesidad de capturar datos de servidores de páginas remotos.
Las bases de datos de Hiperescala tienen un nodo de proceso principal donde se procesan las transacciones y la carga de trabajo de lectura y escritura. Se pueden agregar hasta cuatro nodos de proceso secundarios de alta disponibilidad a petición. Actúan como nodos en espera activa con fines de conmutación por error y pueden servir como nodos de proceso de solo lectura para descargar cargas de trabajo de lectura cuando lo desee. Las réplicas con nombre son nodos de proceso secundarios diseñados para habilitar diversos escenarios adicionales de escalado horizontal de lectura de OLTP y brindar mejor soporte a las cargas de trabajo de procesamiento transaccional y analítico híbrido (HTAP). Se puede agregar un nodo de proceso de replicación geográfica secundaria con fines de recuperación ante desastres y servir como nodo de proceso de solo lectura para descargar cargas de trabajo de lectura en otra región de Azure.
En modo sin servidor, la réplica principal y cualquier réplica de alta disponibilidad o réplicas con nombre se escalan automáticamente en función de su uso. El intervalo de escalado automático de proceso para la réplica principal y las réplicas con nombre se configuran de forma independiente. El intervalo de escalado automático de cualquier réplica de alta disponibilidad se hereda de la configuración de escalado automático especificada por su réplica principal asociada o réplica con nombre.
El motor de base de datos que se ejecuta en nodos de ejecución de Hyperscale es el mismo que en otros niveles de servicio de Azure SQL Database. Cuando los usuarios interactúan con el motor de base de datos en nodos de ejecución de Hyperscale, el área expuesta compatible y el comportamiento del motor son los mismos que en otros niveles de servicio, con la excepción de limitaciones conocidas.
Servidor de páginas
Los servidores de páginas son sistemas que representan un motor de almacenamiento escalado horizontalmente. Cada servidor de páginas es responsable de un subconjunto de las páginas en la base de datos. Cada servidor de páginas también tiene una réplica que se mantiene para la redundancia y la disponibilidad.
El trabajo de un servidor de páginas es servir las páginas de la base de datos a los nodos de ejecución a petición, y conservar las páginas actualizadas a medida que las transacciones actualizan los datos. Los servidores de páginas se mantienen actualizados reproduciendo entradas del registro de transacciones del servicio de registro.
Los servidores de páginas también mantienen memorias caché de cobertura basadas en SSD para mejorar el rendimiento. El almacenamiento a largo plazo de las páginas de datos se mantiene en Azure Storage para aumentar la confiabilidad.
Servicio de registros
El servicio de registro acepta registros de transacciones que corresponden a los cambios de datos de la réplica de proceso principal. A continuación, los servidores de páginas reciben las entradas de registro del servicio de registro y aplican los cambios a sus respectivos segmentos de datos. Además, las réplicas secundarias de proceso reciben registros del servicio de registro y solo reproducen los cambios en las páginas que ya están en su grupo de búferes o en la memoria caché local de RBPEX. Todos los cambios en los datos desde la réplica de proceso principal se propagan mediante el servicio de registros a todas las réplicas de proceso secundarias y los servidores de página.
Por último, las entradas de registro de transacciones se insertan en el almacenamiento a largo plazo en Azure Storage, que es un repositorio de almacenamiento casi infinito. Este mecanismo elimina la necesidad de truncamiento frecuente del registro. Las razones habituales del aumento del registro, como las copias de seguridad de registros omitidas o la replicación lenta de datos en réplicas secundarias, no se aplican a Hiperescala. El servicio de registro tiene memoria local y cachés SSD para acelerar el acceso a las entradas de registro.
Almacenamiento de Azure
Azure Storage contiene todos los archivos de datos de una base de datos. Los servidores de página mantienen los archivos de datos en Azure Storage actualizados. Este almacenamiento también se usa con fines de copia de seguridad y se puede replicar entre regiones en función de la elección de redundancia de almacenamiento.
Las copias de seguridad se implementan mediante instantáneas de almacenamiento de archivos de datos. Las operaciones de restauración mediante instantáneas son rápidas independientemente del tamaño de los datos. Una base de datos se puede restaurar a cualquier punto en el tiempo dentro de su período de retención de copia de seguridad.
Hiperescala admite redundancia de almacenamiento configurable. Al crear una base de datos de Hiperescala, puede elegir entre los siguientes tipos de almacenamiento estándar de Azure:
- Almacenamiento con redundancia local (LRS)
- Almacenamiento con redundancia de zona (ZRS)
- Almacenamiento con redundancia geográfica con acceso de lectura (RA-GRS).
- Almacenamiento con redundancia de zona geográfica con acceso de lectura (RA-GZRS)
Las opciones de almacenamiento con redundancia de zona están disponibles en regiones de Azure con zonas de disponibilidad.
La opción de redundancia de almacenamiento seleccionada se usa durante la vigencia de la base de datos tanto para la redundancia de almacenamiento de datos como para la redundancia de almacenamiento de copia de seguridad.