Descargar como PDF, PPTX
Subido porSolidQ
Nuevo motor relacional In-memory OLTP
El documento presenta el nuevo motor relacional In-memory OLTP de SQL Server. Explica que este motor ha sido diseñado para aprovechar las tendencias de hardware actuales como el aumento de la memoria y los cores por socket. El motor almacena los datos y índices completamente en memoria para lograr altísima concurrencia y tiempos de respuesta estables para cargas de trabajo OLTP con altos ratios de escritura. También describe algunas limitaciones y restricciones del motor como la necesidad de reescribir procedimientos para compilarlos de forma nativa.
Más contenido relacionado
Similar a Nuevo motor relacional In-memory OLTP
Nuevo motor relacional In-memory OLTP
- 1. #SQSummit @ Nuevo motor relacionalIn-memory OLTP 400 Mentor [email protected] MCT – MCAD – MCSD – MCSE - MCSA Rubén Garrigós
- 2. Agenda 3 1. Evolución hardware 2.El motor In-Memory 3. Conclusiones
- 3.
- 4. Descenso en elprecio 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 corespor 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
- 7.
- 8. Motor relacional escalablepara 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 datoslatch-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 atacaun 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 Minimizarriesgos Motor In-Memory OLTP
- 13. Creación de tablaslenta Motor In-Memory OLTP CREATE TABLE DDL Convertir a estructura en código C Llamar al compilador Generar la DLL Cargar la DLL
- 14.
- 15. Integración “InterOp” Memory-optimized TableFilegroup 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 paracrear 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 – Nopodemos 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 tablasen 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 enmemoria – 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 – Estos3 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 importantespara 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 importantespara 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
- 25.
- 26. Whitepaper de MicrosoftResearch http://research.microsoft.com/pubs/193594/Hekaton%20- %20Sigmod2013%20final.pdf Gran importancia de usar procs nativos
- 27. Otras limitaciones – Sinsoporte 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 aEnterprise ú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 puntoscalientes
- 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 – Seescribe 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 – Threadpara 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 Checkpointautomá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 alrecovery 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 seha 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 parausuarios 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 / [email protected]