Categorías
Donaciones

Todo el contenido es gratuito y en beneficio de la comunidad. Puedes reconocer el esfuerzo con una donación si lo deseas.

Inserte aquí su publicidad

Archivo de la categoría ‘Varios’

Ya viene SQL Server 2014, lo que significa por lo menos que hay que ponerse a leer para ir aprendiendo. Y eso he hecho, por lo menos de la estrella revolucionaria que esta versión traerá debajo del brazo, in-memory OLTP. Después de unos cuantos whitepapers, guías, blogs, etc., recojo aquí un conjunto de preguntas que yo mismo me he hecho y a las que a algunas le he ido encontrando respuesta de cara a suavizar el golpe a los que comiencen. Lo haré en dos partes, esta primera más del lado técnica (aunque sin profundizar en lo teórico para no perderse), y una segunda más filosófica o reflexiva sobre le cambio. Vayamos a ello.

Hekaton

Nombre en clave de la funcionalidad in-memory OLTP, la estrella en SQL Server 2014. También llamado XTP (extreme transaction processing).

¿Qué es?

La explicación corta, los datos residen permanentemente en memoria, no en disco, con lo que al trabajar siempre en caché, se suprimen a la vez las esperas por disco y las esperas por bloqueos, lo que aumenta dramáticamente el rendimiento.

¿Por qué surge?

El disco es lo más lento de un sistema de bases de datos. El SSD es carísimo. La CPU hace ya bastante que no corre más, de hecho, el escalado va por multiplicar los núcleos y procesadores de un servidor, pero una consulta simple no corre en más de un core. Sin embargo, la memoria es muy barata, al ser casi un consumible de cliente, y puedes montar un servidor con 2 Tb de RAM sin que el coste sea astronómico. La solución pasa por tenerlo todo en memoria.

(Bueno, también surge porque motores de la competencia lo tienen, véase SAP Hana u Oracle Exadata.)

¿Si los datos no están en el disco, dónde están cuando se para el servicio?

Existe un trabajo en background que va salvando a disco los datos cambiados y borrados (aparte, una especie de checkpoint continuo en la sombra para que cuando se pare el servidor, los datos no se pierdan). Se estructuran bloques de 128 Mb y se van realizando las lecturas del log de transacciones para poder hacer el redo o recovery. De hecho, hay dos, el “data” y el “delta” (el delta es en el que se anotan los registros borrados). Cuando se inicia el servicio, como parte del redo o recovery, se suben a memoria los datos (data), todos, salvo los borrados (delta). Examinando el “fichero”, se observa que es un directorio con un buen montón de ficheros, entre los que hay un conjunto de ellos de 128Mb de tamaño.

¿Cómo es que no hay bloqueos?

No hay ningún tipo de bloqueo, se gestionan por snapshot (por defecto) y se controla por timestamp cuál es el valor válido del registro. Al iniciar una actualización, tomas tu versión del registro, lo cambias y se marca, se guardo lo que había y lo nuevo y se diferencia el “estado actual” de la tabla por el timestamp.

¿Cómo se estructuran las páginas en esa memoria?

No, ya no hay páginas. La estructura es totalmente diferente. Son acumulaciones de información de registros en un hash (no en arbol B) en los que en cada registro tiene acoplada la ordenación de cada índice definido para la tabla. De hecho, los registros de una misma tabla no tienen ni por qué estar cerca.

¿Todas las tablas tienen que estar en memoria en una base de datos?

No, no es necesario, puede haber tablas que estén en memoria y tablas que no. Eso sí, hay que marcar la base de datos para que permita la posibilidad de crear tablas in-memory.

¿Cómo es el acceso a los datos?

El T-SQL es el mismo, existe dentro del motor un intérprete que transforma el código a sintaxis para acceder a tablas en memoria. También se pueden construir consultas que mezclen unas tablas en memoria y otras en disco. Sin embargo, para el acceso exclusivo a tablas en memoria, lo ideal es preparar procedimientos almacenados compilados en forma nativa (concepto nuevo también). Hay algunas cosillas raras en la creación de tablas y de estos procedimientos almacenados, pero nada especialmente complicado.

¿Native Compiled Stored Procedures?

La gran ventaja de estos Native Compiled SPs está en que ahorras capas de llamadas a funciones que componen cada operador de un plan de ejecución, puntos intermedios que al final suponen consumo de CPU a la hora de ejecutar un plan de ejecución ya compilado. Estos procedimientos compilados de forma nativa ya van en C, dentro de una DLL que se carga en el sqlsvr.exe, todo está ya dentro. Ojo, esto tiene unas connotaciones importantes para el rendimiento que hay que tener en cuenta, no todo son cosas buenas. Sólo valen para casos en los que todas las tablas implicadas residan en memoria.

¿Vale todo? ¿Qué no se puede hacer?

Hay bastantes, las que son más significativas para mí son:

  • No se pueden usar tipos de datos grandes, estando cada registro está limitado a 8000 bytes potenciales. Ni varchar(max) ni ningún otro blob de los que siguen estando en esta versión.
  • No se pueden modificar las tablas con un ALTER (hay que borrar y volver a crear). Y los índices se crean con la tabla, no se pueden crear después. Tampoco se pueden truncar tablas.
  • La intercalación también está muy restringida (sólo de Windows, _BIN2 para campos que estén indexados).
  • Tampoco puede hacerse una consulta a dos tablas que estén en distintas bases de datos (ni un inner join ni un inser..select).
  • No todas las funciones están admitidas, aunque sí la mayoría.
  • Tampoco se pueden crear cursores (evitando así el oxímoron).
  • No se pueden usar identities (hay que usar secuencias).

¿Se puede pasar una tabla en disco a tabla en memoria?

Sí, eso facilita mucho las migraciones. Aunque hay que hacer notables adaptaciones en las aplicaciones.

¿Y para el ETL?

Pues también, sobre todo para cuando se tienen que guardar tablas de staging. Hay una funcionalidad concreta que permite no tener que persistir nada, sólo se conserva la estructura (tipo tempdb, pero en memoria). Al no tener que escribir nada en disco, el rendimiento se dispara. Cuando le pasa algo al servicio, estas tablas se crean de nuevo vacías (algo que de todas formas ya se hace por el mero significado de ellas, son intermedias que se “truncan” y cargan en cada ejecución del proceso).

Conclusión

El resumen es que la idea no es en qué tablas y aplicaciones emplear Hekaton, sino en qué casos no podrá ser utilizado, ya que la diferencia potencial en rendimiento es la que hay entre la velocidad de un disco y la memoria. Hay que tener reservas y tener también muy claro que hay que cuidarse de querer solucionar problemas con esto, orientándolo más a desarrollos nuevos o a mejorar/escalar desarrollos existentes que ya afinados.

Preguntas del más allá (sin respuesta, algunas)

¿Por qué tras tanto empeño de MS (y el resto) en el cloud, ahora esta monstruosa funcionalidad orientada 100% al on-premisse?

Si se buscaba optimizar la escritura en OLTP, ¿por qué no va tempdb, donde se producen entorno al 50% de las escrituras, de forma nativa, dentro de memoria (y no va, al menos por ahora, con la de limitaciones que hay con la intercalación)?

¿Y no hay nada más que esto? Por supuesto que sí, aunque sin duda esta funcionalidad es la principal novedad.

Bibliografía

Algunos de los documentos y referencias consultadas, así como documentación para profundizar.

http://blogs.technet.com/b/dataplatforminsider/archive/2013/08/01/hardware-considerations-for-in-memory-oltp-in-sql-server-2014.aspx

http://en.wikipedia.org/wiki/Hekaton_(database)

http://download.microsoft.com/download/F/5/0/F5096A71-3C31-4E9F-864E-A6D097A64805/SQL_Server_Hekaton_CTP1_White_Paper.pdf

http://technet.microsoft.com/es-es/evalcenter/dn205290.aspx

http://msdn.microsoft.com/en-us/library/dn133186(v=sql.120).aspx

http://technet.microsoft.com/en-us/library/dn296374(v=sql.120).aspx

http://research.microsoft.com/pubs/193594/Hekaton%20-%20Sigmod2013%20final.pdf

http://blogs.msdn.com/b/arvindsh/archive/2013/07/03/sql-2014-in-memory-oltp-hekaton-training-videos-and-white-papers.aspx


Uso de cookies

Este sitio web utiliza cookies para que usted tenga la mejor experiencia de usuario. Si continúa navegando está dando su consentimiento para la aceptación de las mencionadas cookies y la aceptación de nuestra política de cookies, pinche el enlace para mayor información.plugin cookies