Tablas optimizadas de memoria: ¿pueden ser realmente tan difíciles de mantener?

Estoy investigando los beneficios de la actualización de MS SQL 2012 a 2014. Uno de los grandes puntos de venta de SQL 2014 son las tablas optimizadas de memoria, que aparentemente hacen que las consultas sean súper rápidas.

Descubrí que existen algunas limitaciones en las tablas con memoria optimizada, como:

• No hay (max)campos de tamaño
• Máximo ~ 1 KB por fila
• Sin timestampcampos
• No hay columnas calculadas
• Sin UNIQUErestricciones

Todos estos califican como molestias, pero si realmente quiero evitarlos para obtener los beneficios de rendimiento, puedo hacer un plan.

El verdadero pateador es el hecho de que no puede ejecutar una ALTER TABLEdeclaración, y tiene que pasar por este rigmarole cada vez que agrega un campo a la INCLUDElista de un índice. Además, parece que debe excluir a los usuarios del sistema para realizar cambios en el esquema de las tablas MO en la base de datos en vivo.

Encuentro esto totalmente indignante, en la medida en que realmente no puedo creer que Microsoft haya invertido tanto capital de desarrollo en esta característica, y lo haya dejado tan poco práctico de mantener. Esto me lleva a la conclusión de que debo haber obtenido el extremo equivocado del palo; Debo haber entendido mal algo sobre las tablas optimizadas para la memoria que me ha llevado a creer que es mucho más difícil mantenerlas de lo que realmente es.

Entonces, ¿qué he entendido mal? ¿Has usado tablas MO? ¿Existe algún tipo de cambio o proceso secreto que los haga prácticos de usar y mantener?

No, en la memoria realmente está sin pulir. Si está familiarizado con Agile, conocerá el concepto de "producto mínimo transportable"; en memoria es eso. Tengo la sensación de que MS necesitaba una respuesta a Hana de SAP y su tipo. Esto es lo que podrían depurarse en el plazo para un lanzamiento de 2014.

Como con cualquier otra cosa en la memoria, tiene costos y beneficios asociados. El principal beneficio es el rendimiento que se puede lograr. Uno de los costos es la sobrecarga para la gestión del cambio, como usted mencionó. Esto no lo convierte en un producto inútil, en mi opinión, solo reduce el número de casos en los que proporcionará un beneficio neto. Así como los índices del almacén de columnas ahora se pueden actualizar y los índices se pueden filtrar, no tengo dudas de que la funcionalidad de la memoria mejorará en las próximas versiones.

SQL Server 2016 ahora está generalmente disponible. Tal como supuse, In-Memory OLTP ha recibido varias mejoras. La mayoría de los cambios implementan la funcionalidad que las tablas tradicionales han disfrutado por algún tiempo. Supongo que las funciones futuras se lanzarán al mismo tiempo para las tablas en memoria y tradicionales. Las tablas temporales son un caso en punto. Nuevo en esta versión, es compatible con tablas en memoria y en disco .

Uno de los problemas con la nueva tecnología, especialmente una versión V1 que se ha revelado en voz alta como no completa, es que todos se suben al carro y asumen que es el ajuste perfecto para cada carga de trabajo. No es. El punto óptimo de Hekaton son las cargas de trabajo OLTP de menos de 256 GB con muchas búsquedas de puntos en 2-4 zócalos. ¿Esto coincide con su carga de trabajo?

Muchas de las limitaciones tienen que ver con tablas en memoria combinadas con procedimientos compilados de forma nativa. Por supuesto, puede omitir algunas de estas limitaciones utilizando tablas en memoria pero no utilizando procedimientos compilados de forma nativa, o al menos no exclusivamente.

Obviamente, debe probar si la ganancia de rendimiento es sustancial en su entorno y, si lo es, si las compensaciones valen la pena. Si obtiene grandes ganancias de rendimiento de las tablas en memoria, no estoy seguro de por qué le preocupa cuánto mantenimiento va a realizar en las columnas INCLUDE. Sus índices en memoria cubren, por definición. Estos solo deberían ser realmente útiles para evitar búsquedas en el rango o escaneos completos de índices tradicionales no agrupados, y no se supone que estas operaciones sucedan realmente en tablas en memoria (nuevamente, debe perfilar su carga de trabajo y ver qué operaciones mejoran y que no, no todo es ganar-ganar). ¿Con qué frecuencia muda con columnas INCLUDE en sus índices hoy?

Básicamente, si todavía no vale la pena en su forma V1, no lo use. Esa no es una pregunta que podamos responder por usted, excepto para decirle que muchos clientes están dispuestos a vivir con las limitaciones y están utilizando la función para obtener grandes beneficios a pesar de ellas.

SQL Server 2016

Si está en camino hacia SQL Server 2016, he blogueado sobre las mejoras que verá en In-Memory OLTP, así como la eliminación de algunas de las limitaciones . Más destacado:

• Aumento del tamaño máximo de la tabla duradera: 256 GB => 2 TB
• Columnas LOB / MAX, índices en columnas anulables, eliminación de los requisitos de colación BIN2
• Alterar y recompilar procedimientos
• Algo de soporte para ALTER TABLE: estará fuera de línea, pero debería poder alterar y / o eliminar / volver a crear índices (sin embargo, esto no parece ser compatible con las compilaciones actuales de CTP, así que no tome esto como una garantía)
• Disparadores DML, restricciones FK / check, MARS
• O, NO, EN, EXISTE, DISTINTA, UNIÓN, UNIÓN EXTERNA
• Paralelismo

No puede hacer clic con el botón derecho en una tabla con memoria optimizada para abrir un diseñador y agregar nuevas columnas como desee desde Sql Server Management Studio. Tampoco puede hacer clic dentro del nombre de la tabla como medio para renombrar la tabla. (SQL 2014 al momento de escribir esto).

En su lugar, puede hacer clic con el botón derecho en la tabla y escribir un comando de creación en una nueva ventana de consulta. Este comando de creación se puede modificar agregando nuevas columnas.

Por lo tanto, para modificar la tabla, puede almacenar los datos en una nueva tabla, tabla temporal o variable de tabla. Luego, podría soltar y volver a crear la tabla con el nuevo esquema, y ​​finalmente volver a copiar en los datos reales . Este juego de 3 contenedores es solo un poco menos conveniente para la mayoría de los casos de uso.

Sin embargo, no tendría motivos para molestarse con las tablas de memoria optimizada si no está tratando de resolver un problema de rendimiento.

Luego, tendrá que sopesar si las limitaciones y las soluciones alternativas valen la pena para su caso de uso. ¿Tienes un problema de rendimiento? ¿Has probado todo lo demás? ¿Mejorará esto su rendimiento en 10-100x? Usarlo o no usarlo probablemente terminará siendo un poco obvio de cualquier manera.

puede usar OLTP en memoria en servidores operativos sin ningún problema importante. Utilizamos esta tecnología en una empresa de banca y pagos,

En general, podemos usar tablas con memoria optimizada cuando la carga de trabajo es demasiado alta. ¡Al usar OLTP en memoria puede alcanzar un mejor rendimiento hasta 30X! Microsoft corrige la mayoría de estas limitaciones en SQL Server 2016 y 2017. Las tablas optimizadas para memoria tienen una arquitectura completamente diferente en comparación con las tablas basadas en disco.

Las tablas optimizadas para memoria son dos tipos. Mesas duraderas y no duraderas. Las tablas duraderas y no duraderas mantienen que los datos de la tabla residen en la memoria. Además, las tablas más duraderas conservan datos en Discos para datos y esquemas de recuperación. En la mayoría de los escenarios operativos, deberíamos usar tablas duraderas porque la pérdida de datos es crítica aquí. en algunos escenarios, por ejemplo, carga y almacenamiento en caché de ETL, podemos usar tablas no durables.

Puedes usar estos libros electrónicos y aprender a usar esta tecnología:

Kalen Delaney: https://www.red-gate.com/library/sql-server-internals-in-memory-oltp

Dmitri Korotkevitch: https://www.apress.com/gp/book/9781484227718