Deep Dive Performance , le In-Memory dans SQL Server
Télécharger en tant que PPTX, PDF1 j'aime1,128 vues
Le document traite des nouveautés du SQL Server 2014, mettant en avant le traitement in-memory et les index de colonne pour améliorer la performance des bases de données. Il introduit des concepts tels que les index de colonne optimisés pour la mémoire et le projet Hekaton pour le traitement transactionnel en mémoire. Enfin, il aborde des mythes courants sur ces innovations et leurs avantages dans la gestion des données.
![Migration vers Hekaton
•
Storage
ALTER DATABASE ContosoOLTP ADD FILEGROUP [ContosoOLTP_hk_fs_fg] CONTAINS MEMORY_OPTIMIZED_DATA;
ALTER DATABASE ContosoOLTP
ADD FILE (NAME = [ContosoOLTP_fs_dir],
FILENAME = 'H:MOUNTHEADDATACONTOSOOLTP_FS_DIR') to FILEGROUP [ContosoOLTP_hk_fs_fg];
•
Table
CREATE TABLE Customers (
CustomerID nchar (5) NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT=100000),
CompanyName nvarchar (40) NOT NULL INDEX IX_CompanyName HASH(CompanyName) WITH (BUCKET_COUNT=65536),
ContactName nvarchar (30) NOT NULL ,
ContactTitle nvarchar (30) NOT NULL ,
Address nvarchar (60) NOT NULL ,
Ville nvarchar (15) NOT NULL INDEX IX_Ville HASH(Ville) WITH (BUCKET_COUNT=1024),
Region nvarchar (15) NOT NULL INDEX IX_Region HASH(Region) WITH (BUCKET_COUNT=1024),
PostalCode nvarchar (10) NOT NULL INDEX IX_PostalCode HASH(PostalCode) WITH (BUCKET_COUNT=100000),
Country nvarchar (15) NOT NULL ,
Phone nvarchar (24) NOT NULL ,
Fax nvarchar (24) NOT NULL
) WITH (MEMORY_OPTIMIZED=ON)
•
Native procedure
CREATE PROC InsertCustomers (@CustomerID nchar(5),@CompanyName nvarchar(40),
@ContactName nvarchar(30),@ContactTitle nvarchar(30), @Address nvarchar(60),
@Ville nvarchar(15),@Region nvarchar(15),@PostalCode nvarchar(10),
@Country nvarchar(15),@Phone nvarchar(24),@Fax nvarchar(24))
WITH NATIVE_COMPILATION, SCHEMABINDING, execute as owner as
BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, language = 'english')
INSERT INTO [dbo].[Customers] VALUES(@CustomerID,@CompanyName,@ContactName,@ContactTitle,@Address,
@Ville,@Region,@PostalCode,@Country,@Phone,@Fax);
END
#mstechdays
Bases de données/ Data management](https://image.slidesharecdn.com/datit304koppelpichautaurlienfrdricdeepdiveperformancelein-memoryda-140219102021-phpapp02/85/Deep-Dive-Performance-le-In-Memory-dans-SQL-Server-28-320.jpg)
Deep Dive Performance , le In-Memory dans SQL Server
- 2. Deep Dive Performance le In-Memory dans SQL Server Aurélien Koppel Resp. Tech. de compte (ADM) Microsoft France Frédéric Pichaut Senior Escalation Egineer Microsoft France Bases de données/Data management
- 3. Equipe Microsoft Premier - ADM Développez, déployez et supportez plus efficacement vos applications Bonnes pratiques ALM Transferts d’expertises Accédez directement aux experts Microsoft et groupes produits Corp. Améliorez la qualité de vos développements Réduisez les risques et coûts des projets applicatifs
- 4. Donnez votre avis ! Depuis votre smartphone sur : http://notes.mstechdays.fr De nombreux lots à gagner toute les heures !!! Claviers, souris et jeux Microsoft… Merci de nous aider à améliorer les Techdays ! #mstechdays Bases de données/ Data management
- 5. Sommaire • Introduction au In-Memory dans SQL Server • Les ColumnStore Indexes (v2) • Le In-Memory OLTP (Hekaton) • Conclusion • Questions/Réponses #mstechdays Bases de données/ Data management
- 6. LE IN-MEMORY DANS SQL SERVER 2014 #mstechdays Bases de données/ Data management
- 8. Les nouveaux serveurs aujourd’hui • Server: HP DL580G7 (Environ $50K) • CPU : • 4-socket running Intel Westmere-EX • 10 cores per socket, • 2 threads per core • 80 logical processors • Memoire: 256GB (extensible à 2 TB) • Disques: Controller, disk enclosure, and 25 x 146GB SAS 15K rpm disks #mstechdays Bases de données/ Data management
- 9. Le In-Memory dans SQL Server • BI: xVelocity in-memory analytics engine – PowerPivot (Excel 2010 et >) – Excel 2013 – Analysis Services 2012 – Modèle tabulaire • SQL DataWarehousing: xVelocity memory optimized ColumnStore index – ColumnStore Indexes (SQL Server 2012 et >) • SQL: xVelocity main memory optimized OLTP – Projet Hekaton (SQL Server 2014) #mstechdays Bases de données/ Data management
- 10. LES COLUMN STORE INDEXES (V2) #mstechdays Bases de données/ Data management
- 11. Qu’est ce qu’un CSI? • ColumnStore Index • Nouveau type d’index introduit avec SQL Server 2012 • Membre de la famille “xVelocity” • Stockage: – En mémoire – En colonne – Compressé • Syntaxe de création plus simple que pour des autres types d’indexes: Pas réservé aux « Experts »! #mstechdays Bases de données/ Data management
- 12. Fonctionnement des ColumnStore Indexes Stockage en ligne « Traditionnel » Stockage en colonnes C1 C 2 C3 C4 C5 Bénéfices: • Améliore les calculs d’agrégats: • Pas besoin de parcourir toutes les pages • Améliore la compression: … Les données d’une même colonne ont plus de probabilité d’être redondantes • Réduit les I/O: Ne va chercher que les colonnes nécessaires #mstechdays Bases de données/ Data management
- 13. Pourquoi utiliser les Columnstore Indexes? • Optimiser l’accès à de gros entrepôts de données (pas OLTP) – Schémas en étoile, tables de fait volumineuses – Meilleur Temps de réponse • Transparent pour l’application: – – – – • Requêtes Backup and restore Mirroring, log shipping SSMS, etc. Réduction de l’effort de modélisation de la base de données – Moins d’indexes à créer et maintenir – Réduit le besoin d’agrégats pré-calculés ou de vues indexées – Peut dans certains cas éviter la création de cubes OLAP (Si la performance est le critère principal) #mstechdays Bases de données/ Data management
- 14. Nouveauté SQL Server 2014: Clustered Columnstore Indexes • • Avantages des clustered index: – Economisent de la place Etudier la migration de vos tables en CCSI ou l’utilisation des CCSI pour les nouvelles tables de vos DWH 20.0 Space Used in GB (101 million row table) 15.0 10.0 91% savings 5.0 • • Support de nouveaux types de données • High precision decimal, datatypeoffset, binary, varbinary, uniqueidentifier, etc. • Types non supportés: spatial, XML, max types 0.0 Requêtes DML et DDL supportées – Possibilité de faire évoluer le schéma de la Bases de données/ Data management #mstechdays table ** Space Used = Table space + Index space
- 15. C1 C2 C3 C4 C5 • • C6 DML (update, delete, insert) -> Utilisent le delta store INSERT Values – C1 C2 • C3 C4 C5 C6 • • #mstechdays Si batch < 100k, insert dans le delta store, sinon columnstore SELECT – • DELETE suivi d’un INSERT. BULK INSERT – • Opération logique Donnée effacée physiquement après REBUILD UPDATE – • Toujours dans le delta store DELETE – – tuple mover Column Store Delta (row) store Nouveauté SQL Server 2014: Updatable Columnstore Index Unit les données des Column et Row stores - internal UNION operation. “Tuple mover” convertit les données en mode Column quand le row group est plein (~1M of rows) REORGANIZE statement -> convertit le delta store en column store. Bases de données/ Data management
- 16. Nouveauté SQL Server 2014: Performance Améliorée • Mode mixte d’exécution de requête (row et batch) – • La présence d’opérateurs de type row n’empêche pas les autres opérateurs d’être exécutés en mode batch. De nouveaux opérateurs « batch »: – – – joins (inner, outer) partial/global aggregates w/ and w/o group by union all operator Note: • Les agrégats de type “Distinct” et les opérateurs “UNION” sont toujours exécutés en row mode. #mstechdays Bases de données/ Data management
- 17. DÉMO COLUMN STORE INDEXES #mstechdays Bases de données/ Data management
- 18. Demo Clustered ColumnStore Indexes Dim Date Fact Internet Sales Dim Customer 50 Millions de lignes #mstechdays Bases de données/ Data management Dim Geography
- 19. Demo Clustered ColumnStore Indexes #mstechdays Bases de données/ Data management
- 20. LE IN-MEMORY OLTP (HEKATON) #mstechdays Bases de données/ Data management
- 21. Hekaton: “In-Memory OLTP” • Le “In-Memory OLTP” est l’une des innovations autour de SQL Server 2014 pour titrer le mieux parties de la mémoire et des processeurs • Des éléments spécialisés pour chaque type de workloads: • Column store indexes for SQL Server 2012/2014 and PDW • In-Memory Analytics – Power Pivot for Excel 2010 • App Fabric Cache - mid tier caching solution • Stream Insight : Real time data stream analytics • #mstechdays In-Memory OLTP for SQL Server 2014 Bases de données/ Data management
- 22. Les Mythes sur le In-Memory OLTP 1. SQL Server In-Memory OLTP est une réponse aux offres de nos compétiteurs 2. In-Memory OLTP c’est comme un DBCC PINTABLE 3. In-Memory OLTP est un nouveau produit séparé 4. On peut passer une application au In-Memory OLTP sans aucun changement 5. Comme les tables sont en mémoire, les données ne sont pas durables ou disponibles pour la haute dispo. Tout est perdu après un crash #mstechdays Bases de données/ Data management
- 23. Mythe #1 • SQL Server In-Memory OLTP est une réponse aux offres de nos compétiteurs Le projet “Hekaton” a commencé il y plus de 4 ans en réponse aux besoins business et évolutions hardware. Pur produit de Microsoft Research #mstechdays Bases de données/ Data management
- 24. Mythe #2 • In-Memory OLTP c’est comme un DBCC PINTABLE In-memory OLTP est un nouveau design pour optimiser les opérations sur les données en mémoire. Il n’y a pas de pages ou buffer pool pour les memory-optimized tables. #mstechdays Bases de données/ Data management
- 25. Mythe #3 • In-Memory OLTP est un nouveau produit séparé In-Memory OLTP complétement intégré à SQL Server 2014 #mstechdays Bases de données/ Data management
- 26. Hekaton Architecture Client App TDS Handler and Session Management Natively Compiled SPs and Schema Parser, Catalog, Optimizer Native Compiler T-SQL Query Execution Query Interop T 1 T 2 T 3 Tables Indexes T 1 Memory Optimized Data Filegroup #mstechdays Buffer Pool for Tables & Indexes SQL Server.exe Memory Optimized Tables & Indexes T 2 T 3 Transaction Log Bases de données/ Data management T 1 T 2 Data Filegroup T 3 Key Existing SQL Componen In-mem t OLTP Componen t Generated .dll
- 27. Mythe #4 • On peut passer un application au InMemory OLTP sans aucun changement Il y a quelques modifications à faire, au minimum dans le schéma. Modifications plus faciles si on utilise déjà des Stored Procedures #mstechdays Bases de données/ Data management
- 28. Migration vers Hekaton • Storage ALTER DATABASE ContosoOLTP ADD FILEGROUP [ContosoOLTP_hk_fs_fg] CONTAINS MEMORY_OPTIMIZED_DATA; ALTER DATABASE ContosoOLTP ADD FILE (NAME = [ContosoOLTP_fs_dir], FILENAME = 'H:MOUNTHEADDATACONTOSOOLTP_FS_DIR') to FILEGROUP [ContosoOLTP_hk_fs_fg]; • Table CREATE TABLE Customers ( CustomerID nchar (5) NOT NULL PRIMARY KEY NONCLUSTERED HASH WITH (BUCKET_COUNT=100000), CompanyName nvarchar (40) NOT NULL INDEX IX_CompanyName HASH(CompanyName) WITH (BUCKET_COUNT=65536), ContactName nvarchar (30) NOT NULL , ContactTitle nvarchar (30) NOT NULL , Address nvarchar (60) NOT NULL , Ville nvarchar (15) NOT NULL INDEX IX_Ville HASH(Ville) WITH (BUCKET_COUNT=1024), Region nvarchar (15) NOT NULL INDEX IX_Region HASH(Region) WITH (BUCKET_COUNT=1024), PostalCode nvarchar (10) NOT NULL INDEX IX_PostalCode HASH(PostalCode) WITH (BUCKET_COUNT=100000), Country nvarchar (15) NOT NULL , Phone nvarchar (24) NOT NULL , Fax nvarchar (24) NOT NULL ) WITH (MEMORY_OPTIMIZED=ON) • Native procedure CREATE PROC InsertCustomers (@CustomerID nchar(5),@CompanyName nvarchar(40), @ContactName nvarchar(30),@ContactTitle nvarchar(30), @Address nvarchar(60), @Ville nvarchar(15),@Region nvarchar(15),@PostalCode nvarchar(10), @Country nvarchar(15),@Phone nvarchar(24),@Fax nvarchar(24)) WITH NATIVE_COMPILATION, SCHEMABINDING, execute as owner as BEGIN ATOMIC WITH (TRANSACTION ISOLATION LEVEL = SNAPSHOT, language = 'english') INSERT INTO [dbo].[Customers] VALUES(@CustomerID,@CompanyName,@ContactName,@ContactTitle,@Address, @Ville,@Region,@PostalCode,@Country,@Phone,@Fax); END #mstechdays Bases de données/ Data management
- 29. Mythe #5 • Comme les tables sont en mémoire, les données ne sont pas durables ou disponibles pour la haute dispo. Tout est perdu après un crash Le In-Memory OLTP est compatible avec les composants HA, incluant AlwaysOn Les données sont résidentes sur disque, et survivent à un crash. On peut aussi travailler avec des tables volatiles #mstechdays Bases de données/ Data management
- 30. Concurrence d’accès #mstechdays Bases de données/ Data management
- 31. Hash Indexes Hash index with (bucket_count=8): Hash mapping: f(Jean) Array of 8-byte Memory pointers #mstechdays f(Jules) f(Laura) 0 1 2 3 4 5 6 7 f(Paris) f(Toulon), f(Nice) Bases de données/ Data management Fonction de hashing f: • Mape les valeurs aux buckets • Dans le système Hash Collisions
- 32. Memory Optimized Tables et Indexes Timestamps Hash index Nom f(Jean) 50, ∞ Pointeurs Nom Ville Hash index Ville Jean Paris f(Paris) f(Laura) f(Toulon) 90, ∞ #mstechdays Laura Toulon Bases de données/ Data management
- 33. Memory Optimized Tables et Indexes Timestamps Hash index Nom f(Jules) Pointeurs 50, ∞ Nom Ville Hash index Ville Jean Paris f(Paris) 100, ∞ Jules Paris 90, ∞ Laura Toulon T100: INSERT (Jules, Paris) #mstechdays Bases de données/ Data management
- 34. Memory Optimized Tables et Indexes Timestamps Hash index Nom Pointeurs 50, ∞ Nom Ville Hash index Ville Jean Paris 100, ∞ Jules Paris 90, ∞ 90, 150 Laura Toulon T150: DELETE (Laura, Toulon) #mstechdays Bases de données/ Data management
- 35. Memory Optimized Tables et Indexes Timestamps Hash index Nom f(Jules) Pointeurs 50, ∞ 100, ∞ 100, 200 Nom Ville Hash index Ville Jean Jules Paris Paris f(Nice) 200, ∞ 90, 150 Jules Laura Nice Toulon T200: UPDATE (Jules, Paris) to (Jules, Nice) #mstechdays Bases de données/ Data management
- 36. Memory Optimized Tables et Indexes Timestamps Hash index Nom f(Jean) f(Jules) Pointeurs 50, ∞ Nom Ville Hash index Ville Jean Paris f(Paris) 100, 200 Jules Paris f(Nice) 200, ∞ 90, 150 Jules Laura Nice Toulon T250: Garbage collection #mstechdays Bases de données/ Data management
- 37. BEGIN AMR • Analysis, Migrate and Report Tool • Configure Management Data Warehouse, • Configure Data Collection, and run AMR Reports to identify performance hotspots Establish System Performance Baseline Run workload Is MDW Set up? Run AMR Reports Configure Management Data Warehouse Migrate Configure Data Collection Run Workload and collect performance metrics Compare to Baseline and set as new baseline COMPLETE #mstechdays Bases de données/ Data management
- 38. AMR Report • Table Analysis • Usage Analysis • Contention analysis • Store Procedure Analysis • Usage Analysis #mstechdays Bases de données/ Data management
- 39. Limitations dans SQL 2014 (V1) • Optimisation pour l’OLTP – No DML triggers – No XML and no CLR data types • Optimisation in-memory – Rows are at most 8060 bytes – no off row data – No Large Object (LOB) types like varchar(max) • Limitations de schéma – No FOREIGN KEY and no CHECK constraints – No IDENTITY – No schema changes (ALTER TABLE) – need to drop/recreate table – No add/remove index – need to drop/recreate table #mstechdays Bases de données/ Data management
- 40. Hekaton en bref • Un ajout au moteur SQL pour l’OLTP, optimisé pour une gestion en mémoire – Support des propriétés ACID – Le but de la V1 est spécifiquement orienté vers l’OLTP • Complètement intégré au moteur SQL Server – Un avantage sur nos compétiteurs – Une approche Hybride entre le In-memory et le traditionnel • Obtenir de la performance en éliminant le plus possible d’instruction – Des indexes optimisés en mémoire • Dissocié de la structure disque. Pas de B+tree, ni de buffer pool – Plus de mécanisme de locks & latches • Gestion de concurrence optimiste, – L’optimisation faite lors de la compilation • T-SQL compilé en code natif C #mstechdays Bases de données/ Data management
- 41. DEMO HEKATON #mstechdays Bases de données/ Data management
- 42. CONCLUSION #mstechdays Bases de données/ Data management
- 43. Le In-Memory dans SQL Server • BI: xVelocity in-memory analytics engine – PowerPivot (Excel 2010 et >) – Excel 2013 – Analysis Services 2012 – Modèle tabulaire • SQL DataWarehousing: xVelocity memory optimized ColumnStore index – ColumnStore Indexes (SQL Server 2012 et >) • SQL: xVelocity main memory optimized OLTP – Projet Hekaton (SQL Server 2014) #mstechdays Bases de données/ Data management
- 44. Ressources Sessions Data Insights pour les professionnels de l’IT http://aka.ms/itprosql Sessions Data Insights pour les décideurs informatiques http://aka.ms/itdmsql Business Accelerator, un programme sur mesure pour les éditeurs de logiciel http://aka.ms/isvbusacc Un client prêt à témoigner ? Une belle histoire à partager ? Un Nokia Lumia à gagner ! http://aka.ms/cloudosref #mstechdays Bases de données/ Data management
Notes de l'éditeur
- #32: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #33: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #34: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #35: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #36: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #37: Talking points:A table is a collection of row versions – validity of a row version at a point in time is indicated by the timestampThe buckets of a hash index are simply memory pointers to the first row in the bucketAll indexes on memory optimized tables are inherently coveringNo separate clustered index – table/index structure different from b-trees/heaps in disk-based tablesNo bookmark lookupAll row versions in the bucket are chained together into a linked listJean and Jules are in the same bucket “J”; thus the last row version of “Jules” points to the first row version of “Jean”A second index is again a collection of pointers to rows. In this case to the cities Nice and ParisAgain, rows in each bucket are chained through pointers between the rows – as you can see in this example, different indexes can have different chains of row versions in their bucketsThe Hekaton Garbage collector periodically removes row versions that are no longer valid for any active transaction – this means, e.g., that long-running transactions can force a lot of old row versions to stay in memory, and, e.g., cause memory pressure – discussed later in the DBA section of this presentation
- #44: -1min