SQL Server 2014 introdujo una nueva tecnología en memoria llamada Hekaton. Esta tecnología ha ganado mucha atención y ha generado muchos conceptos erróneos y mitos. En esta publicación de blog, abordaremos algunos de los conceptos erróneos más comunes y proporcionaremos una comprensión clara de los conceptos básicos de Hekaton.

Mito #1: Hekaton es una tecnología en memoria, lo que significa que los datos ya no se persisten

Esto no es cierto. Hekaton todavía proporciona las propiedades ACID para transacciones, lo que significa que sus datos todavía se persisten. Las transacciones en Hekaton son atómicas, consistentes, aisladas y duraderas. SQL Server utiliza diferentes conceptos e implementaciones internamente para garantizar estas propiedades. Sus datos sobrevivirán a un bloqueo de SQL Server si ha habilitado la durabilidad del esquema y los datos.

Mito #2: Hekaton solo se ejecuta en arquitecturas de CPU específicas

Esto es completamente falso. Hekaton utiliza operaciones Atomic CAS, que son compatibles con una amplia gama de arquitecturas de CPU. La función de ensamblaje requerida ha sido compatible desde el procesador Pentium. Siempre que esté ejecutando SQL Server 2014 en un sistema operativo Windows compatible, puede usar Hekaton.

Mito #3: Hekaton es el nuevo enfoque No-SQL de Microsoft

Hekaton no es un producto No-SQL. Todavía es una base de datos relacional con todas las propiedades ACID. Hekaton utiliza un enfoque más eficiente para implementar las características de una base de datos relacional.

Mito #4: Hekaton solo funciona en arquitecturas de CPU específicas

Hekaton está libre de bloqueos, cerrojos y spinlocks dentro de su propio universo. Sin embargo, al interactuar con el motor relacional tradicional de SQL Server, como el Administrador de registros de transacciones, los bloqueos y spinlocks todavía están presentes. Además, puede ocurrir contención durante las operaciones Atomic CAS, lo que puede resultar en hilos girando y aumentando la latencia de la transacción.

Mito #5: Hekaton proporciona una lógica empresarial súper rápida dentro de la base de datos

Aunque Microsoft puede promover esta afirmación desde una perspectiva de licencia, no se recomienda realizar una lógica empresarial extensa dentro de la base de datos. Una base de datos debe centrarse en almacenar y recuperar datos, mientras que la lógica empresarial debe ser manejada por servidores de aplicaciones dedicados.

Mito #6: Mover una base de datos completa de SAP a Hekaton

No se recomienda mover una base de datos completa a Hekaton. Hekaton está diseñado para resolver problemas específicos, como la contención de cerrojos. Es más apropiado mover tablas y procedimientos almacenados específicos a Hekaton, en lugar de toda la base de datos.

En conclusión, Hekaton es una tecnología poderosa que puede mejorar significativamente el rendimiento en los escenarios adecuados. Sin embargo, es importante comprender sus limitaciones y utilizarlo de manera apropiada. No olvide hacer su tarea y abordar cualquier problema de rendimiento tradicional antes de considerar Hekaton. Si tiene alguna pregunta o comentario, no dude en compartirlos a continuación.

¡Gracias por leer!