Nuevo motor relacional In-memory OLTP
•
1 recomendación•495 vistas
http://summit.solidq.com Presentación realizada por Rubén Garrigós en el SolidQ Summit 2014.
Recomendados
Más contenido relacionado
Similar a Nuevo motor relacional In-memory OLTP
Similar a Nuevo motor relacional In-memory OLTP (20)
Más de SolidQ
Más de SolidQ (20)
Último
Último (19)
Nuevo motor relacional In-memory OLTP
- 1. #SQSummit @ Nuevo motor relacional In-memory OLTP 400 Mentor rgarrigos@solidq.com MCT – MCAD – MCSD – MCSE - MCSA Rubén Garrigós
- 2. Agenda 3 1. Evolución hardware 2. El motor In-Memory 3. Conclusiones
- 4. Descenso en el precio por GB Aumento en la frecuencia y ancho de banda Memoria máxima instalable en aumento – 2005 2S Xeon 7020 64 GB – 2009 2S X5680 288GB – 2011 8S E7-8870 4 TB – 2013 2S E5-2667 v2 768 GB – 2014 8S E7 v3 12 TB Futura NVRAM Memoria 5
- 5. Aumento de cores por socket en x86/x64 – 2006 1 o 2 cores por socket – 2008 8 cores – 2010 12 cores – 2012 16 cores – 2014 20 cores? Aumento en la capacidad de proceso total Aumento modesto en rendimiento por core Las diferencias cada vez son menores entre generaciones CPU
- 6. Sistemas de almacenamiento – Precio por TB en descenso – Precio por IOPS en descenso Las SAN siguen siendo caras para un sistema dedicado – SSDs + HDDs en DAS para DW – SSDs PCI-e para OLTP – Combinar con grupos de disponibilidad Sistemas 100% sobre SSD y RAM Entrada/salida
- 8. Motor relacional escalable para OLTP de altísima concurrencia – Porcentaje de escrituras muy alto – Lógica de procedimientos pesada/no orientada a conjuntos – Tiempos de respuesta estables Alinearse con las tendencias hardware de los últimos años Capa de acceso muy escalable horizontalmente Interoperable con el motor tradicional – Acceso a tablas de los dos motores • Transacciones entre tablas in-memory y tradicionales Objetivos de diseño
- 9. Estructura de datos ~100% en memoria Locks + Spinlocks + Latches Concurrencia optimista opcional Indexación con B-Trees Planes compilados pero siempre interpretados MAXDOP 1, paralelismo no aprovechable en OLTP Ratios de escritura altos son problemáticos – Concurrencia – Log manager Motor “tradicional” en OLTP a día de hoy
- 10. Estructuras de datos latch-free en RAM Control de concurrencia optimista con versionado de filas Tablas hash & Bw-trees Código compilado vs interpretado Tablas volátiles o persistentes Sin paralelismo en las ejecuciones Decisiones técnicas
- 11. Si se ataca un componente la mejora es limitada – Relational Engine Verde – Storage Engine Azul – IO + Scheduling Gris El nuevo motor sustituye a casi todos estos componentes Optimizar la comunicación entre cliente y server – Llamadas a RPC directas a procs nativos – Embeber la lógica de negocio en procs nativos Enfoque global
- 12. Lenguaje T-SQL Reutilización de componentes Minimizar riesgos Motor In-Memory OLTP
- 13. Creación de tablas lenta Motor In-Memory OLTP CREATE TABLE DDL Convertir a estructura en código C Llamar al compilador Generar la DLL Cargar la DLL
- 15. Integración “InterOp” Memory-optimized Table Filegroup Data Filegroup TDS Handler and Session Management Natively Compiled SPs and Schema Buffer Pool for Tables & Indexes Proc/Plan cache for ad-hoc T-SQL and SPs Transaction Log Query Interop Memory_optimized Tables & Indexes • Non-durable • Durable Tables & Indexes T1 T4 T3 T2 T1 T4 T3 T2 T1 T4 T3 T2 T1 T4 T3 T2 Tables Indexes Interpreter for TSQL, query plans, expressions T1 T4 T3 T2 T1 T4 T3 T2 Checkpoint & Recovery Access Methods Parser, Catalog, Algebrizer, Optimizer Hekaton Compiler
- 16. Restricciones importantes para crear tablas – FKs y CHECKS no soportados – Collation BIN2 – No soporta tipos de datos “especiales” (XML, CLR, varchar(max), etc.) – Longitud total <=8060 bytes en definición Otras restricciones para crear tablas – Se necesita siempre una PK – No se soportan triggers – Creación tablas lenta – No se pueden modificar ni renombrar, hay que recrearlas Motor In-Memory OLTP
- 17. Indexación – BUCKET_COUNT correcto • Entre 1 y 2 veces el número de valores únicos de la clave • Por defecto Más colisiones • Por exceso Más consumo de memoria y scans más lentos – 8 índices • Máximo 1 UNIQUE, para la PK No se puede modificar con un update • Todos incluyen todas las columnas Consumo de memoria multiplicado – No se pueden añadir o modificar a posteriori, se definen con la tabla – No pueden ser filtrados – No pueden incluir valores NULLables Motor In-Memory OLTP
- 18. Indexación hash – No podemos contar con claves que “cubran” prefijos comunes – Hash afecta a todas las claves del índice – No se optimizan operaciones como LIKE ‘prefijo%’ Indexación Bw-tree – Búsquedas de rango, recorridos en orden (no a la inversa) – Tamaño de páginas hoja variable – Páginas intermedias no se modifican, se recrean y reapuntan • Tamaño máximo 8 KB Split • Tamaño mínimo 10% o 1 fila Merge – Páginas hojas, se crean páginas delta con las diferencias • Más de 16 cambios enlazados se consolida Motor In-Memory OLTP
- 19. Estadísticas en tablas en memoria – Creación automática o manual – Siempre fullscan y norecompute – La actualización siempre manual – La actualización no es bloqueante para procs nativos No caer en el error de descuidar su mantenimiento – Spill a tempdb en queries adhoc sobre tablas in-memory – Consumo de CPU excesivo en procedimientos nativos Motor In-Memory OLTP
- 20. 100% garantizadas en memoria – Ayudan a reducir la congestion en Tempdb – SQL 2014 mejora el eager write para Tempdb Necesitan un create type, no se pueden definir inline al vuelo Son útiles como contenedores – Para los resultados intermedios – Como parámetros de tipo tabla Variables de tipo tabla In-Memory
- 21. SNAPSHOT REPEATABLE READ SERIALIZABLE – Estos 3 son definibles en la clausula ATOMIC en procs nativos READ COMMITTED Solo en statements independientes Transacciones Cross-Container típicas – MEMORY_OPTIMIZED_ELEVATE_TO_SNAPSHOT – Hint WITH (SNAPSHOT) para la tabla In-Memory Niveles de aislamiento In-Memory
- 22. READ COMMITTED READ_COMMITTED_SNAPSHOT Statements independientes sin acceso a tablas en disco REPEATABLE READ/SERIALIZABLE Si se inicia desde TSQL interpretado se deben acceder a tablas en memoria con SNAPSHOT SNAPSHOT Si se inicia desde TSQL interpretado no se puede acceder a tablas en memoria Niveles aislamiento
- 23. Restricciones MUY importantes para compilar un procedimiento – Solo pueden acceder a tablas in-memory – Cambios en las estadísticas no refrescan el código generado • Debemos tener datos y estadísticas frescas ANTES de crearlo • Regenerar después de cada update statistics – Se consideran todos los parámetros de entrada como UNKNOWN • Evitamos problemas de parameter sniffing • Pero podemos obtener planes menos óptimos Limitaciones
- 24. Restricciones MUY importantes para compilar un procedimiento – OR, IN, NOT, LIKE, CASE, UNION, OUTER JOIN, APPLY, PIVOT, INTERSECT, EXCEPT… – Subqueries, funciones, TVF, CTEs, windowing, ranking, … – EXEC – ROLLUP, CUBE, GROUPING SETS, DISTINCT – Tablas temporales / Vistas – Inserts de múltiples filas a la vez con VALUES, OUTPUT – DELETE/UPDATE con FROM – TOP (int) + SORT < 8192 filas con 1 join, < 4096 con 2 joins.. – Largo etc. Limitaciones
- 26. Whitepaper de Microsoft Research http://research.microsoft.com/pubs/193594/Hekaton%20- %20Sigmod2013%20final.pdf Gran importancia de usar procs nativos
- 27. Otras limitaciones – Sin soporte de transacciones entre bases de datos o distribuidas (solo con tempdb) – No soporta MERGE con target in-memory – No soporta cursores dynamic ni keyset, tampoco API de cursor – Nos fuerza a incluir en la aplicación lógica de reintentos más compleja – Reinicios de instancia más costosos Grupos de disponibilidad – Solo en Enterprise Edition Limitaciones colaterales
- 28. Si vamos a Enterprise únicamente por In-Memory… – Hasta 4 sockets/16 cores físicos Hasta 32 lógicos con HT – Hasta 128 GB de RAM + Buffer Pool Extension de hasta 512 GB – 1200€ vs 5000€ por core 4.16x > 60K en 16 cores Si ya tenemos Enterprise – Buscar puntos con contención por locks/latches/spinlocks – Buscar algoritmos iterativos fila a fila – Buscar algoritmos con pasos con tablas temporales intermedias – Buscar puntos con mucha escritura en el log de transacciones Standard vs Enterprise
- 29. DEMO Aplicando In-Memory en puntos calientes
- 30. – CHECKDB/CHECKTABLE – Replicación – Auditoría/change tracking – Fulltext – Filestream – Compresión – Encriptación – Partitioning – Mirroring – Database snapshots – MARS – Linked Servers – Y un largo etc. Limitaciones colaterales
- 31. Log stream – Se escribe al final de la transacción, antes del commit, no durante la transacción transacciones cortas – Solo se registran los cambios en datos, no en índices – Al transaction log, lo mínimo y empaquetado por filas – La latencia al log sigue siendo crítica SSD – Los updates siempre delete + insert Checkpoint streams – Checkpoint File Pairs - CFPs – Data streams Todas las versiones de filas insertadas – Delta streams Versiones de filas borradas Persistencia a disco
- 32. Offline checkpoint – Thread para checkpoint en background – Estilo logreader – Reducir los picos – Enfoque similar al incremental checkpoint Ficheros de datos y delta Memory Optimized Data Filegroup Range 300-399 Range 100-199 Range 200-299 Range 400-499 Range 500- offline checkpoint Thread
- 33. Persistencia a disco Checkpoint automático al llegar a 512 MB de log El proceso de checkpoint solo actualiza metadatos y fuerza flush a disco A partir del último checkpoint, los CFPs y la cola del log se produce el recovery Se busca que los pares de datos y delta tengan un tamaño controlado de hasta 128 MB una transacción grande lo puede exceder Recomendable no tener más de 256 GB en tablas In-memory – Dimensionar para 500 GB y 4000 CFPs – Si llegamos a 1 TB o 8000 CFPs Stall
- 34. Recovery En paralelo al recovery tradicional Paralelismo máximo 1 thread por core 1 CFP por thread – Leer los ficheros – Crear los índices – Fuerza bruta de IO
- 35. Conclusiones In-Memory OLTP se ha diseñado pensando en hardware actual y su evolución previsible Aplicable a escenarios concretos, no en general Es necesario rediseño y/o adaptación de aplicaciones Puede sustituir complejos sistemas de caché Esto es solo una V1 pero la apuesta de MS es fuerte – Creemos que el futuro del OLTP es sobre tablas en memoria – Si ya tienes Enterprise Edition, aprovecha y sácale partido Un OLTP con mucha concurrencia de peticiones muy fuertemente optimizadas puede ser una bomba de relojería
- 36. 43 Power BI para usuarios de negocio 43 Curso online Clases virtuales presenciales 14, 15, 16, 21, 22 y 23 de Julio De 16 a 20 h Máster en BI 4ª Edición (Inicio Octubre 2014) - Clases presenciales virtuales - 450 horas (60 ECTS) - SolidQ – UPM - Clases + trabajo práctico + proyecto - Beca de hasta 1.300 € para los primeros inscritos. Máster en Big Data & Analytics 1ª Edición (Inicio Octubre 2014) - Clases presenciales virtuales - 1 año (60 ECTS) UMA - Clases + trabajo práctico + proyecto Información e inscripción: http://university.solidq.com / ibinfo@solidq.com