Tablas In-Memory en Sql Server 2014 Hekaton

31.12.2013 17:56

Entre las nuevas funciones de SQL Server 2014 destaca una nueva capacidad de base de datos en memoria, cuyo nombre en código es "Hekaton". Hekaton mejora drásticamente el rendimiento y la latencia de procesamiento de las transacciones de SQL Server. Lo que es más impresionante de Hekaton es que se logra una mejora en las capacidades de SQL Server  sin necesidad de un producto de gestión de datos independiente o de  un nuevo modelo de programación. 

Sql Server utiliza  los sistemas de gestión de datos en memoria en los índices de almacenamiento de columna y las cargas de trabajo analíticas gracias al motor de análisis xVelocity e índices de almacén de columnas xVelocity. El indice de almacén de columnas xVelocity se actualizará también en SQL Server 2012 Data Warehouse Parallel (PDW v2) para apoyar a los índices de columnas agrupadas actualizables. Hekaton, en cambio, es una tecnología basada en filas completamente  centrada en el procesamiento de transacciones (TP) y las cargas de trabajo. Tenga en cuenta que estos dos enfoques no son mutuamente excluyentes. La combinación de Hekaton y el motor xVelocity de índice de almacén de columnas y análisis xVelocity existente en SQL Server, se traducirá en una gran combinación.

El hecho de que Hekaton y el índice de almacén de columnas xVelocity están incorporados a SQL Server, en lugar de estar en un motor de datos separado, es una opción de diseño consciente. Otros proveedores están introduciendo memorias optimizadas en cachés separadas o la construcción de una capa de unificación en un conjunto de tecnologías como un producto completamente nuevo. Esto agrega complejidad al forzar a los clientes a implementar y administrar un producto completamente nuevo, o peor aún, administrar tanto un producto "optimizador de memoria" para los datos en caliente y un producto "de almacenamiento optimizado" para los datos de aplicación que no es rentable que estén  principalmente en memoria.


Durante la mayor parte de sus operaciones de procesamiento de datos con In-Memory OLTP , puede no ser consciente de que está trabajando con las tablas de memoria optimizada en lugar de tablas basadas en disco . Sin embargo, SQL Server está trabajando con sus datos de manera muy diferente si se almacenan en las tablas de memoria optimizada.

 

¿Qué hay de especial en In-Memory OLTP ?
Aunque In-Memory OLTP está integrado con el motor relacional de SQL Server, y se puede acceder mediante las mismas interfaces de forma transparente, su comportamiento y sus capacidades internas son muy diferentes. En el gráfico siguiente se  ofrece una visión general del motor de SQL Server con los componentes OLTP en memoria.



Observe que la aplicación cliente se conecta al controlador de TDS de la misma manera en las tablas de memoria optimizada que en las tablas basadas en disco, tanto si se va a llamar a procedimientos almacenados compilados de forma nativa o al intérprete de Transact -SQL. Se puede ver que el intérprete de  Transact -SQL puede acceder a las tablas de memoria optimizada utilizando las capacidades de interoperabilidad, pero que los procedimientos almacenados compilados de  forma nativa sólo pueden  acceder a las tablas de memoria optimizada.


Tablas de memoria optimizada
La diferencia más importante entre tablas de memoria optimizada y tablas basadas en disco es que las páginas no tienen que ser leídas en la memoria caché del disco cuando se accede a las tablas de memoria optimizada. Todos los datos se almacenan en  memoria, todo el tiempo. Se crea un conjunto de archivos de punto de control (pares de datos y archivos delta ) , que sólo se utilizan con fines de recuperación , en archivos que residen en filegroups  de memoria optimizada que hacen un seguimiento de los cambios en los datos y se anexa – solamente, los archivos de punto de control
Las operaciones en las tablas de memoria optimizada  utilizan el mismo registro de transacciones que se utilizan para las operaciones en tablas basadas en disco , y como siempre, el registro de transacciones se almacenan en el disco. En caso de una caída del sistema o un apagado del servidor, las filas de datos de las tablas de memoria optimizada pueden recrearse a partir de los archivos de punto de control y el registro de transacciones.


In-Memory OLTP proporciona la opción de crear una tabla que es no - duradera y no conectada  mediante una opción llamada SCHEMA_ONLY. Como indica la opción, el esquema de la tabla será duradero, a pesar de que los datos no lo sean. Estas tablas no requieren ninguna operación de IO durante el procesamiento de transacciones, pero los datos sólo están disponibles en memoria  mientras SQL Server se está ejecutando. En el caso de un cierre de SQL Server o una Conmutación por error de AlwaysOn, los datos de estas tablas se pierden. Las tablas  se volverán a crear cuando la base de datos a la que pertenecen se recupere, pero no habrá datos en  las tablas. Estas tablas pueden ser útiles, por ejemplo como  tablas en escenarios de ETL o para almacenar el estado de sesión del servidor Web. Aunque los datos no son duraderos, las operaciones en estas tablas  cumplen todos los demás requisitos transaccionales, son atómicas, aisladas, y consistentes.


Los índices de las tablas de memoria optimizada
Los índices de las tablas de memoria optimizada no se almacenan como los B-trees tradicionales. Los Índices de las tablas de memoria optimizada soportan  hash, almacenados como tablas hash con listas enlazadas que conectan todas las filas con  el mismo valor hash e índices de rango, lo que se almacena utilizando BW- trees especiales. Los índices no agrupados en tablas de memoria optimizada  no estaban disponibles antes de CTP2. ,
Cada tabla  de memoria optimizada  debe tener por lo menos un índice, ya que son los índices los que combinan todas las filas en una sola tabla. Las Tablas de memoria optimizada nunca se almacenan como conjuntos desorganizados de filas, como se almacenan las tablas basadas en disco

Los Índices nunca se almacenan en el disco,  no se reflejan en los archivos de log  en el disco y las operaciones realizadas  sobre índices nunca se registran. Los índices se mantienen automáticamente durante todas las operaciones de modificación en las tablas de memoria optimizada, al igual que los índices de b -tree en tablas basadas en disco, pero en caso de que se reinicie SQL Server, los índices de las tablas de memoria optimizada se reconstruyen así que los datos sean  transmitidos a la memoria.


Mejoras de concurrencia
Al acceder a las tablas de memoria optimizada, SQL Server implementa un control de concurrencia multi - versión optimizado. Aunque SQL Server ha sido previamente descrito como capaz de soportar  el control de concurrencia optimizado con los niveles de aislamiento basados ​​en instantáneas(snapshots)  introducidos en SQL Server 2005, ya que, estos llamados métodos optimizados no adquieren bloqueos durante las operaciones de modificación de datos . Para las tablas de memoria optimizada, no hay bloqueos adquiridos, y por lo tanto no hay que esperar a causa de bloqueo.
Tenga en cuenta que esto no significa que no hay posibilidad de espera cuando se utiliza tablas de memoria optimizada. Hay otros tipos de espera, tales como la espera de escritura de registro para completar al final de una transacción. Sin embargo, el registro al hacer cambios en las tablas de memoria optimizada  es mucho más eficiente que el registro para tablas basadas en disco , por lo que los tiempos de espera será mucho más cortos . Y nunca habrá ninguna espera a  la lectura de datos desde el disco, y tampoco espera a bloqueos  de las filas de datos .


Procedimientos almacenados Nativamente  Compilados
Se obtiene el mejor rendimiento de ejecución al utilizar procedimientos almacenados compilados  de forma nativa con las tablas de memoria optimizada. Sin embargo, existen limitaciones en las construcciones del lenguaje Transact -SQL que se permiten dentro de un procedimiento almacenado compilado  de forma nativa en comparación con el amplio conjunto de funciones disponibles con código interpretado. Además, los procedimientos almacenados compilados de forma nativa sólo pueden acceder a las tablas de memoria optimizada y no pueden hacer referencia a tablas basadas en disco