Optimización del rendimiento mediante las tecnologías en memoria de Azure SQL Database

Se aplica a:Azure SQL Database

Las tecnologías en memoria permiten mejorar el rendimiento de las aplicaciones y pueden reducir el costo de las bases de datos.

Cuándo usar tecnologías en memoria

Mediante el uso de las tecnologías en memoria, puede lograr mejoras de rendimiento con diversas cargas de trabajo:

  • Transaccionales [procesamiento transaccional en línea (OLTP)] en las que la mayoría de las solicitudes leen o actualizan conjuntos de datos más pequeños, por ejemplo, operaciones de creación, lectura, actualización y eliminación (CRUD).
  • Análisis [procesamiento analítico en línea (OLAP)] donde la mayoría de las consultas tienen cálculos complejos con fines de informes, y también procesos programados periódicamente que realizan operaciones de carga (o carga masiva) o escriben cambios de datos en tablas existentes. A menudo, las cargas de trabajo OLAP se actualizan periódicamente desde cargas de trabajo OLTP.
  • Mixtas (procesamiento analítico-transaccional híbrido (HTAP)) en las que las consultas OLTP y OLAP se ejecutan en el mismo conjunto de datos.

Las tecnologías en memoria pueden mejorar el rendimiento de dichas cargas de trabajo al conservar en la memoria los datos que se deben procesar mediante la compilación nativa de las consultas o el procesamiento avanzado (como el procesamiento por lotes y las instrucciones SIMD) disponibles en el hardware subyacente.

Información general

Azure SQL Database admite las siguientes tecnologías en memoria:

  • OLTP en memoria aumenta el número de transacciones por segundo y reduce la latencia de su procesamiento. Estas son las situaciones en las que se obtienen ventajas con OLTP en memoria: procesamiento de transacciones de alto rendimiento, como operaciones comerciales y juegos, ingesta de datos de eventos o dispositivos de IoT, almacenamiento en caché, carga de datos y escenarios de tablas temporales y variables de tablas.
  • Los índices de almacén de columnas en clúster reducen el espacio de almacenamiento necesario (hasta 10 veces) y mejoran el rendimiento de las consultas de análisis e informes. Puede usarlos con las tablas de hechos de sus data marts para incluir más datos en la base de datos y mejorar el rendimiento. También puede usarlos con los datos históricos de la base de datos operativa para archivar hasta 10 veces más datos, así como para disfrutar de un incremento equivalente en el número de consultas realizadas sobre ellos.
  • Con los índices de almacén de columnas no clúster para HTAP, podrá obtener información en tiempo real sobre su negocio realizando consultas directamente a la base de datos operativa, sin necesidad de ejecutar un caro proceso de extracción, transformación y carga (ETL) ni esperar a que se rellene el almacén de datos. Los índices de almacén de columnas no en clúster permiten una ejecución rápida de las consultas de análisis en la base de datos OLTP y, a la vez, reducen el impacto en la carga de trabajo operativa.
  • Los índices de almacén de columnas en clúster optimizados para memoria para HTAP le permiten realizar el procesamiento de transacciones de manera rápida y ejecutar consultas de análisis simultáneamente de manera muy rápida en los mismos datos.

Los índices de almacén de columnas y OLTP en memoria se introdujeron en SQL Server en 2012 y 2014, respectivamente. Azure SQL Database, Azure SQL Managed Instance y SQL Server comparten la misma implementación de tecnologías en memoria.

Nota:

Para ver un tutorial detallado paso a paso para demostrar las ventajas de rendimiento de la tecnología OLTP en memoria, con la base de datos de ejemplo AdventureWorksLT y ostress.exe, consulte Ejemplo en memoria en Azure SQL Database.

Ventajas de la tecnología en memoria

Gracias al procesamiento más eficiente de las consultas y las transacciones, las tecnologías en memoria también lo ayudan a reducir costos. Normalmente no necesita actualizar el plan de tarifa de la base de datos para lograr mejoras de rendimiento. En algunos casos, tal vez pueda reducir incluso el plan de tarifa sin dejar de observar mejoras de rendimiento con las tecnologías en memoria.

Gracias al uso de OLTP en memoria, Quorum Business Solutions pudo duplicar la carga de trabajo al mismo tiempo que mejoró las DTU en un 70 %. Para obtener más información, consulte OLTP en memoria en Azure SQL Database).

Nota:

Las tecnologías en memoria están disponibles en los niveles Premium y Crítico para la empresa de Azure SQL Database.

En este artículo, se describen aspectos de OLTP en memoria y los índices de almacén de columnas específicos de Azure SQL Database junto con algunos ejemplos:

  • Veremos la repercusión de estas tecnologías en el almacenamiento, así como en los límites de tamaño de los datos.
  • Después trataremos cómo administrar el movimiento de bases de datos que usan estas tecnologías entre los distintos planes de tarifa.
  • Y también veremos dos ejemplos que ilustran el uso de OLTP en memoria y de los índices del almacén de columnas.

Para obtener más información sobre OLTP en memoria en SQL Server, consulte:

OLTP en memoria

La tecnología OLTP en memoria proporciona operaciones de acceso a datos sumamente rápidas al mantener todos los datos en memoria. Además, usa índices especializados, compilación nativa de consultas y acceso a datos libre de bloqueos temporales para mejorar el rendimiento de la carga de trabajo OLTP. Hay dos maneras de organizar los datos de OLTP en memoria:

  • El formato almacén de filas optimizadas para memoria, en el que cada fila es un objeto de memoria independiente. Se trata de un formato clásico de OLTP en memoria optimizado para cargas de trabajo OLTP de alto rendimiento. Existen dos tipos de tablas optimizadas para memoria que se pueden usar en el formato de almacén de filas optimizadas para memoria:

    • Tablas duraderas (SCHEMA_AND_DATA), en las que las filas que se encuentran en la memoria se conservan después de reiniciar el servidor. Este tipo de tablas se comporta como una tabla de almacén de filas tradicional, con las ventajas adicionales de las optimizaciones en memoria.
    • Tablas no duraderas (SCHEMA_ONLY), en las que las filas no se conservan después del reinicio. Este tipo de tabla está diseñado para datos temporales (por ejemplo, tablas temporales o de reemplazo) o para tablas en las que necesite cargar datos rápidamente antes de moverlos a alguna tabla persistente (denominadas "tablas de almacenamiento provisional").
  • El formato Almacén de columnas optimizadas para memoria, en el que los datos se organizan en un formato de columnas. Esta estructura está diseñada para escenarios HTAP donde es necesario ejecutar consultas analíticas en la misma estructura de datos en la que se está ejecutando la carga de trabajo OLTP.

Nota:

La tecnología de OLTP en memoria está diseñada para las estructuras de datos que pueden residir completamente en memoria. Puesto que no se pueden descargar los datos en memoria en el disco, asegúrese de usar una base de datos que tenga memoria suficiente. Consulte Límite de almacenamiento y tamaño de datos para OLTP en memoria para obtener más información.

Límite de almacenamiento y tamaño de datos para OLTP en memoria

OLTP en memoria incluye tablas optimizadas para memoria, que se usan para almacenar los datos de los usuarios. Estas tablas deben caber en la memoria. Dado que administra la memoria directamente en SQL Database, tenemos el concepto de una cuota para datos de usuario. Esta idea se conoce como almacenamiento de OLTP en memoria.

Cada plan de tarifa de grupo elástico y de base de datos única admitido incluye una cantidad determinada de almacenamiento de OLTP en memoria.

Los siguientes elementos cuentan para su límite de almacenamiento de OLTP en memoria:

  • Las filas de datos de usuarios activos en tablas optimizadas para memoria y variables de tabla. Las versiones antiguas de las filas no cuentan para el límite.
  • Los índices de tablas optimizadas para memoria.
  • La sobrecarga operacional de operaciones ALTER TABLE.

Si alcanza el límite, recibirá un error que le notificará que se ha quedado sin cuota y no podrá volver a insertar o actualizar datos. Para mitigar este error, elimine datos o aumente el plan de tarifa de la base de datos o del grupo.

Para obtener más información sobre cómo supervisar la utilización del almacenamiento de OLTP en memoria y configurar alertas que se activen cuando casi haya alcanzado el límite, consulte Supervisión del almacenamiento en memoria.

Acerca de los grupos elásticos

Con grupos elásticos, el almacenamiento de OLTP en memoria se comparte entre todas las bases de datos del grupo. Por lo tanto, el uso de una base de datos puede afectar a otras bases de datos. Existen dos formas de mitigar este problema:

  • Configure un valor Max-eDTU o MaxvCore para las bases de datos que sea inferior al recuento de eDTU o núcleos virtuales del grupo como un todo. De este modo, se limita la utilización del almacenamiento de OLTP en memoria en cualquier base de datos del grupo al tamaño correspondiente al número de eDTU.
  • Configure un valor Min-eDTU o MinvCore que sea mayor que 0. Este mínimo garantiza que cada base de datos del grupo tenga la cantidad de almacenamiento de OLTP en memoria disponible que corresponda al valor Min-eDTU o vCore configurado.

Cambio de los niveles de servicio de las bases de datos que usan tecnologías de OLTP en memoria

Siempre puede actualizar su base de datos a un plan superior, como de uso General (núcleo virtual) a Crítico para la empresa o de Estándar (DTU) a Premium. Solo aumenta la funcionalidad y los recursos disponibles.

Pero cambiar a un nivel inferior puede repercutir negativamente en la base de datos. El impacto es especialmente evidente al cambiar de Crítico para la empresa a De uso general (o de Premium a Estándar o Básico) cuando la base de datos contiene objetos de OLTP en memoria. Puede encontrar fácilmente objetos en memoria en la base de datos.

Las tablas optimizadas para memoria no están disponibles después del cambio a una versión anterior (aunque sigan estando visibles). Lo mismo se aplica al reducir el plan de tarifa de un grupo elástico o mover bases de datos con tecnologías en memoria a un grupo elástico De uso general, Estándar o Básico.

Importante

OLTP en memoria no se admite en los planes DTU De uso general, Estándar o Básico de Azure SQL Database. Por lo tanto, no es posible mover una base de datos con objetos de OLTP en memoria a uno de estos niveles. Antes de degradar el plan de una base de datos, quite todos los tipos de tabla y las tablas optimizadas para memoria, así como todos los módulos de T-SQL compilados de forma nativa o conviértalos a objetos basados en filas.

Reducir verticalmente los recursos en el plan Crítico para la empresa: Los datos de las tablas optimizadas para memoria deben caber en el almacenamiento de OLTP en memoria asociado al plan de la base de datos o disponible en el grupo elástico. Si trata de reducir verticalmente el plan o mover la base de datos a un grupo que no disponga de almacenamiento de OLTP en memoria suficiente, la operación no se desarrolla correctamente.

Determinar si existen objetos en memoria

No existe ningún mecanismo de programación para comprender si una base de datos específica admite OLTP en memoria. Puede ejecutar la siguiente consulta de Transact-SQL:

SELECT DatabasePropertyEx(DB_NAME(), 'IsXTPSupported');

Si la consulta devuelve 1, OLTP en memoria se admite en esta base de datos.

Las siguientes consultas identifican todos los objetos que deben quitarse antes de que el nivel de una base de datos pueda degradarse a De uso general, Estándar o Básico:

SELECT * FROM sys.tables WHERE is_memory_optimized=1
SELECT * FROM sys.table_types WHERE is_memory_optimized=1
SELECT * FROM sys.sql_modules WHERE uses_native_compilation=1

Almacén de columnas en memoria

La tecnología de almacén de columnas en memoria es lo que le permite almacenar y consultar una gran cantidad de datos en las tablas. La tecnología de almacén de columnas usa el formato de almacenamiento de datos basado en columnas y procesamiento de consultas por lotes para lograr hasta 10 veces el rendimiento de las consultas en las cargas de trabajo OLAP con almacenamiento tradicional orientado a filas. También puede lograr ganancias de hasta 10 veces la compresión de datos sobre el tamaño de los datos sin comprimir.

Hay dos tipos de modelos de almacén de columnas que puede usar para organizar los datos:

  • Almacén de columnas en clúster donde todos los datos en la tabla se organizan con el formato de columnas. En este modelo, todas las filas de la tabla se colocan en un formato de columnas que comprime enormemente los datos y le permite ejecutar informes y consultas analíticas rápidas en la tabla. Según la naturaleza de los datos, el tamaño de los datos puede disminuirse entre 10 y 100 veces. El modelo de almacén de columnas en clúster también permite la ingesta rápida de grandes cantidades de datos (carga masiva), ya que los lotes grandes de datos con más de 100 000 filas se comprimen antes de almacenarse en el disco. Este modelo es una buena elección para los escenarios de almacenamiento de datos clásicos.
  • Almacén de columnas no en clúster, donde los datos se almacenan en una tabla de almacén de filas tradicional y hay un índice en formato de almacén de columnas que se usa para las consultas analíticas. Este modelo permite el procesamiento analítico-transaccional híbrido (HTAP): la capacidad de ejecutar análisis en tiempo real de alto rendimiento en una carga de trabajo transaccional. Las consultas OLTP se ejecutan en la tabla de almacén de filas que está optimizada para tener acceso a un pequeño conjunto de filas, mientras que las consultas OLAP se ejecutan en el índice de almacén de columnas, que es la mejor opción para exámenes y análisis. El optimizador de consultas elige dinámicamente el formato de almacén de filas o almacén de columnas en función de la consulta. Los índices de almacén de columnas no en clúster no reducen el tamaño de los datos, ya que el conjunto de datos original se conserva en la tabla de almacén de filas original sin realizar ningún cambio. Sin embargo, el tamaño del índice de almacén de columnas adicional debe ser, en orden de magnitud, menor que el índice de árbol B equivalente.

Nota:

La tecnología de almacén de columnas en memoria conserva únicamente los datos que se necesitan para su procesamiento en la memoria, mientras que los datos que no quepan en la memoria se almacenan en disco. Por lo tanto, la cantidad de datos en las estructuras de almacén de columnas en memoria puede superar la cantidad de memoria disponible.

Almacenamiento y tamaño de datos para los índices de almacén de columnas

No se requiere que los índices de almacén de columnas quepan en la memoria. Por lo tanto, el único límite del tamaño de los índices es el tamaño máximo global de la base de datos, que está documentado en los artículos sobre el modelo de compra basado en DTU y el modelo de compra basado en núcleo virtual.

Al utilizar los índices de almacén de columnas en clúster, se emplea una compresión de columnas para el almacenamiento de la tabla base. Esta compresión puede reducir considerablemente el consumo de almacenamiento de sus datos de usuario, lo que significa que la base de datos podrá albergar más información. Y es posible aumentar este compresión aún más con la compresión de archivo de columnas. La cantidad de compresión que puede lograr depende de la naturaleza de los datos, pero no es raro obtener una compresión que reduzca el tamaño en 10 veces.

Por ejemplo, si tiene una base de datos con el tamaño máximo de 1 terabyte (TB) y logra una compresión de 10 veces con índices de almacén de columnas, puede incluir un total de 10 TB de datos de usuario en la base de datos.

Al utilizar índices de almacén de columnas no agrupados, la tabla base sigue almacenada en el formato de almacenamiento de filas tradicional. Por lo tanto, el ahorro de almacenamiento no es tan considerable como con los índices de almacén de columnas agrupados. Pero si sustituye numerosos índices no agrupados tradicionales por un único índice de almacén de columnas, aún podrá obtener un ahorro global en el espacio de almacenamiento de la tabla.

Cambio de los niveles de servicio de las bases de datos que contienen índices de almacén de columnas

Cambiar una base de datos única a un plan Básico o Estándar no sería posible si el nivel de destino está por debajo de S3. Los índices de almacén de columnas solo se admiten en los planes de tarifa Premium, Crítico para la empresa y Estándar (S3 y superior), no en el plan Básico. Si se cambia la base de datos a un nivel inferior incompatible, el índice de almacén de columnas dejará de estar disponible. El sistema mantiene el índice de almacén de columnas, pero nunca utiliza el índice. Si, más tarde, vuelve a actualizar a un plan o nivel superior compatible, el almacén de columnas estará listo inmediatamente para volver a usarse.

Si tiene un índice de almacén de columnas en clúster, toda la tabla deja de estar disponible después del cambio a un nivel inferior. Quite todos los índices de almacén de columnas agrupados (y reemplace por índices agrupados de almacén de filas) antes de cambiar la base de datos a un nivel no admitido.