Novedades deSQL Server 2014 en Motor Relacional | SolidQ Summit 2014
•
0 gefällt mir•478 views
http://summit.solidq.com Presentación realizada por Enrique Catalá durante el SolidQ Summit 2014.
Empfohlen
Empfohlen
Weitere ähnliche Inhalte
Was ist angesagt?
Was ist angesagt? (20)
Ähnlich wie Novedades deSQL Server 2014 en Motor Relacional | SolidQ Summit 2014
Ähnlich wie Novedades deSQL Server 2014 en Motor Relacional | SolidQ Summit 2014 (20)
Mehr von SolidQ
Mehr von SolidQ (20)
Kürzlich hochgeladen
Kürzlich hochgeladen (11)
Novedades deSQL Server 2014 en Motor Relacional | SolidQ Summit 2014
- 1. #SQSummit @enriquecatala Novedades de SQL Server 2014 en Motor Relacional Mentor ecatala@solidq.com MVP – MCT – MCSE Enrique Catalá Bañuls
- 2. Agenda 2 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras en motor On-Disk
- 3. In-Memory motor relacional En SQL Server 2014 4 In-Memory OLTP • 5-30x rendimiento en OLTP • Integrado en SQL Server In-Memory DataWarehouse • 5-25x rendimiento • Elevada compression • Soporta clustered y escrituras Buffer pool extension • Mejora transparente • Hasta 3x rendimiento Aplicación directa en cargas de trabajo Entornos OLTP altamente concurrentes Entornos BI con DW grandes y agregaciones masivas Entornos transaccionales sobre OnDisk de grandes volúmenes de datos
- 4. Pilares In-Memory OLTP 5 Integracion completa • T-SQL conocido • Mismas herramientas • Integrado completamente en SQL Server (sin licencia extra) Optimizado para memoria RAM • Nuevas estructuras de almacenamiento • Sin Buffer Pool • Punteros a datos • Todo son índices de cobertura Alta concurrencia • Gestión de concurrencia optimista multiversion • Soporte ACID • Nuevo motor con algorimos lock-free • Sin latches T-SQL supereficiente • T-SQL compilado a código máquina en C • Los SP son DLL • Compilaciones superagresivas a código máquina
- 6. Agenda 7 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras en motor On-Disk
- 7. • Disco y memoria • Integrado en el core • Beneficios • 10x-100x mas rápido • Transparente • Facil implantación In-Memory DataWarehouse Columnar indexes 8 C 1 C 2 C 3 C 5 C 6 C 4 Columnstore Index Representation
- 8. • Unidad básica de transferencia disco- memoria • Contiene valores de una sola columna • Row Group=filas de varios segmentos • Cada segmento en LOB diferente In-Memory DataWarehouse Segmentos 9 C1 C2 C3 C5 C6C4 Row group Segments
- 10. • Clustered y actualizables NUEVO! • Particionado NUEVO! • Elevada compresión NUEVO! • No es necesario más índices • Pensados para grandes volúmenes • Tabla en nuevo formato • No duplica espacio In-Memory DataWarehouse Beneficios 11
- 11. In-Memory DataWarehouse Diferencias 12 NONCLUSTERED columnstore CLUSTERED columnstore • SQL Server 2014 • Write-read • Estructura nueva de objeto • Contiene deltastore en rowstore temporal y deltas • SQL Server 2012+ • Readonly • Duplica espacio • Contiene subset de columnas
- 13. In-Memory DataWarehouse Compresión 14 19.7GB 10.9GB 5.0GB 4.0GB 6.9GB 1.8GB TABLE WITH CUSTOMARY INDEXING TABLE WITH CUSTOMARY INDEXING (PAGE COMPRESSION) TABLE WITH NO INDEXING TABLE WITH NO INDEXING (PAGE COMPRESSION) TABLE WITH COLUMNSTORE INDEX CLUSTERED COLUMNSTORE
- 14. Agenda 15 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras en motor On-Disk
- 15. • Caché de segundo nivel • Optimización transparente OLTP (3x- 10x) • Durable Buffer pool extension 16 ALTER SERVER CONFIGURATION SET BUFFER POOL EXTENSION { ON ( FILENAME = 'os_file_path_and_name' , SIZE = <size> [ KB | MB | GB ] ) | OFF }
- 17. Buffer pool extension 19 Beneficios Buenas prácticas • Tamaño hasta 1:32 RAM:BPE • Recomendado 1:4 a 1:8 • Testear, impacto negativo en escrituras • Transparencia • Maximizar ROI hardware actual • Minimizar cuellos de botella I/O • Más barato que RAM en grandes cantidades • Valido para Standard Edition
- 18. Agenda 20 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras en motor On-Disk
- 20. Resource Governor 22 SQL Server 2012 • # Resource pools 64 (antes 20) • AFFINITY para vincular a nodos NUMA • Nuevo CAP_CPU_PERCENT • Se gobiernan multipage allocations (nuevo memory manager) SQL Server 2014 • Limitar IOPS por volumen
- 21. Resource Governor para IO Nuevo! 23 CREATE RESOURCE POOL pool_name [ WITH ( [ MIN_CPU_PERCENT = value ] [ [ , ] MAX_CPU_PERCENT = value ] [ [ , ] CAP_CPU_PERCENT = value ] [ [ , ] AFFINITY {SCHEDULER = AUTO | (Scheduler_range_spec) | NUMANODE = (NUMA_node_range_spec)} ] [ [ , ] MIN_MEMORY_PERCENT = value ] [ [ , ] MAX_MEMORY_PERCENT = value ] [ [ , ] MIN_IOPS_PER_VOLUME = value ] [ [ , ] MAX_IOPS_PER_VOLUME = value ]) ]
- 23. Agenda 25 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras en motor On-Disk
- 24. Desafios resueltos en las VLT Very Large Tables 26 Mantenimiento Rendimiento • Entorno transaccional • Reportes • Índices • Estadísticas • Historificación • Espacio
- 25. DEMO 27 Desafios resueltos en las VLT
- 26. Agenda 28 1. In-Memory OLTP 2. In-Memory DataWarehouse 3. Buffer Pool Extension 4. Resource Governor para IO 5. Operaciones online 6. Mejoras motor On-Disk
- 27. Relajado el proceso de envío de páginas sucias a disco para tempdb Tempdb Por fin! 29 Select into … #tmp • Bulk inserts • Select into .. #tmp SORT_IN_TEMPDB • Creacion de índices con SORT_IN_TEMP_DB Tablas temporales en RAM en % elevado Optimización directa solo por migrar
- 28. Cardinality estimator El mayor cambio en el motor “OnDisk” desde SQL Server 7.0 30 • Aporta el nº de registros involucrados en la sentencia (en cada paso) • Estima el recuento de filas afectadas • Aporta distribución de valores • Aporta info distinct count • Aporta info sobre duplicados Estimarselectividaddelpredicado WHERE
- 29. • Se decide el algoritmo de obtención de datos • Malas interpretaciones producen • Malos planes de ejecución • Mal rendimiento de consultas Cardinality estimator El mayor cambio en el motor “OnDisk” desde SQL Server 7.0 31
- 30. Cardinality estimator Desde SQL Server 7.0 hasta SQL Server 2012 32 Independencia • Distribución de datos independiente de unos campos a otros salvo que se indique lo contrario Uniformidad • Los valores se distribuyen uniformemente Contenido • Si algo se busca será porque existe • Si una table se cruza, será porque existe el dato en ambas • El rango menor se asume contenido en el mayorInclusión • En equijoin se assume que el valor existe ¿Acaso eso sucede?
- 31. Threshold update statistics En SQL Server 2008 R2 SP1 33
- 33. Novedades en SQL Server 2014 Que no dan tiempo en esta sesión… 36 AlwaysON • Hasta 8 secundarios • 4 síncronos • Soporte nativo para cloud • Leer secundarios con principal caido Gestión • Backups autogestionados • Herramientas de análisis para migrar a In-Memory • Mejor soporte ExtendedEvents • Estadísticas incrementales Entornos híbridos • Atachar ficheros de BBDD en cloud • Backups a la nube • Migración a la nube Con WS2012 R2 • 640 Cores • 4Tb de RAM • Virtual • 64 cores y 1Tb ram • Soporte SMB Direct 3.0 Seguridad • Cifrado de backups • Nuevos roles y permisos granulares Desarrollo • SQL Server Data Tools • Ahora para BI
- 34. Resumen Exprime al máximo tu HW actual !!! 37 In-memory • In-memory OLTP • In-memory DW • Buffer pool extension Administración • Mejoras en operaciones online • Resource governor para IO On-disk • Nuevo cardinality estimator • Reescritura de componente clave planes ejecución • Estadísticas incrementales La mayor actualización desde SQL Server 2005 Escalabilidad vertical Mejorar disponibilidad del dato Migrar == optimizar¿?
- 35. ¡Gracias! Siéntate a comer con nosotros o tómate un café y aclara tus dudas 39 @enriquecatala Mentor – MVP SQL Server Enrique Catalá Bañuls
Hinweis der Redaktion
- En esta sesión trataremos las novedades de SQL Server 2014 en el área de motor relacional. Trataremos en profunidad las siguientes tecnologías: Buffer Pool Extension, mejoras en Resource Governor 2.0, novedades en índices columnares indexes, mejoras en particionado, estadísticas e indexación
- Lets start off by taking a look at how in-memory technologies have evolved in SQL Server. This may be a surprise to many of you, but our in-memory journey actually started way back in SQL Server 2008 R2, when our engineering team made a key design decision to build in-memory technology into the core data platform, rather than acquire and stitch in an in-memory solution to run in parallel to the core database. Around this timeframe, both Oracle and IBM went down the acquire-and-stitch route: Oracle acquired TimesTen in-memory database and IBM acquired Natiza. The challenge with the acquire-and-stitch solution is that in-memory impacts to the overall database, which in the past were designed to run on disk. So the challenge we often hear from customers using TimesTen or Natiza is that using in-memory breaks other core DB2 and Oracle database functionality. For example, we have heard from many customers that RAC break when you use TimesTen. Not only is there a functional compatibility issue, the customer is also forced to learn a new set of APIs because it is a completely different database. This is not the design approach we took. We believe our customers want to utilize other key capabilities that SQL Server and the broader Microsoft Data Platform have to offer in conjunction with in-memory. They don’t want to use a different tool set for in-memory database than they do for disk database, they still wan to use T-SQL and SQL Server management when enabling in-memory. This is the unique design approach we took back when we first started improving analytics by building in-memory into PowerPivot for billions for rows of data analysis in Excel. Then in SQL Server 2012, we expanded our in-memory footprint with the same built-in approach by adding in-memory to Analysis Services so IT could build data models much faster, and introduced an in-memory column store that could improve query speeds by 100x. With SQL Server 2014, we are covering the final workload by introducing an in-memory OLTP solution—or in-memory rowstore—to significantly speed transactional performance. We also enhanced the in-memory columnstore with faster performance and significantly higher data compression so memory utilization can be optimized. Now, here’s one point to note if you listened to the keynote at Oracle openworld. Larry announced a new in-memory columnstore that would be built-in to the core database. So as you can see Oracle is following our footsteps and realizing the stitch strategy doesn’t work when it comes to something as critical to the overall database as in-memory. And he also mentioned that it will be an optio—we all know what that means. And their new solution is in an early beta. SQL Server 2014 is our third release of in-memory solutions across the data platform, and in a single sku, no options or add ons.
- Demo muy light emplazando a la sesión de ruben garrigos
- Table consists of column store and row store DML (update, delete, insert) operations leverage delta store INSERT Values Always lands into delta store DELETE Logical operation Data physically remove after REBUILD operation is performed. UPDATE DELETE followed by INSERT. BULK INSERT if batch < 100k, inserts go into delta store, otherwise columnstore SELECT Unifies data from Column and Row stores - internal UNION operation. “Tuple mover” converts data into columnar format once segment is full (1M of rows) REORGANIZE statement forces tuple mover to start.
- size of a rowgroup is 102,400 rows For small bulk loads with less than 102,400 rows, all of the rows go directly to the deltastore.
- Durable = solo almacena páginas limpias por lo que si reinicia sql server no se pierden datos
- CAP_CPU_PERCENT permite especificar realmente que se establece un tope máximo fijo a la conexión independientemente de si hay o no competencia por recursos. En un entorno donde “si quieres mas, pagas mas”, esta configuración es mejor que utilizar MAX_CPU_PERCENT
- The ability to govern physical IO only applies to user operations and not system tasks. System tasks include write operations to the transaction log and Lazy Writer IO operations. The Resource Govenor applies primarily to user read operations because most write operations are typically performed by system tasks.
- Existe el concepto eager writes, por el cual, cada vez que ocurre una carga masiva, el propio SQL Server envía en bloques de 32 páginas sucias contiguas (las nuevas generalmente) a disco, para minimizar el impacto sobre el buffer pool, checkpoints y sobre lazy writer. Esto afectaba a tempdb también hasta ahora. For example: You could have a stored procedure that runs in 8ms. In that stored procedure you select into … #tmp … then use the #tmp and drop it as the stored procedure completes. Prior to the SQL Server 2014 change the select into may have written all the pages accumulated to disk. The SQL Server 2014, eager write behavior, no longer forces these pages to disk as quickly as previous versions. This behavior allows the pages to be stored in RAM (buffer pool), queried and the table dropped (removed from buffer pool and returned to free list) without ever going to disk as long memory is available. By avoiding the physical I/O when possible the performance of the TEMPDB, bulk operation is significantly increased and it reduces the impact on the I/O path resources as well.
- En definitiva, estimar la selectividad de WHERE, JOIN y HAVING Muy útil la lectura http://blogs.technet.com/b/dataplatforminsider/archive/2014/03/17/the-new-and-improved-cardinality-estimator-in-sql-server-2014.aspx
- Infravalorar el nº de filas Usar plan en serie cuando debería ser paralelo Operadores join inapropiados Uso de índice inadecuado (seek vs scan) Sobrevalorar nº de filas Seleccionar plan paralelo cuando debe ser serie Operadores join inapropiados Uso de índice inadecuado (scan vs seek) Sobre dimensionar requerimientos ram
- Acaso esto se cumple en la vida real?
- Esto es necesario para entender la demo
- En esta demo veremos los cambios sobre el cardinality estimator y estadísticas incementales
- Todo esto se traduce en Incrementar ROI actual