Deep Dive Performance , le In-Memory dans SQL Server

Bases de données/Data management

Deep Dive Performancele In-Memory dans SQL

ServerAurélien KoppelResp. Tech. de compte (ADM)

Microsoft France

Frédéric PichautSenior Escalation Egineer

Microsoft France

Equipe Microsoft Premier - ADMDéveloppez, déployez et supportez plus efficacement vos applications

Transferts d’expertises

Bonnes pratiques ALM

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

#mstechdays Bases de données/ Data management

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 !

Donnez votre avis !

http://notes.mstechdays.fr/


• Introduction au In-Memory dans SQL Server

• Les ColumnStore Indexes (v2)• Le In-Memory OLTP (Hekaton)• Conclusion• Questions/Réponses

Sommaire

Bases de données/ Data management

#mstechdays

LE IN-MEMORY DANS SQL SERVER 2014


Tendances - Mémoire

1990

1991

1991

1991

1992

1992

1993

1993

1994

1994

1994

1995

1995

1996

1996

1996

1997

1997

1998

1998

1999

1999

2000

2000

2000

2001

2001

2002

2002

2003

2004

2004

2005

2007

2007

2008

2008

2009

2009

2010

2011

1

10

100

1000

10000

100000

1000000

US$ per GB of PC Class MemorySource: http://jcmit.com/memoryprice.htm

US$/

GB


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


• 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)

Le In-Memory dans SQL Server


#mstechdays

LES COLUMN STORE INDEXES (V2)


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 »!


…

C1 C2

C3 C5C4

Fonctionnement des ColumnStore Indexes

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

Stockage en ligne« Traditionnel »

Stockage en colonnes


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)


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

• Support de nouveaux types de données• High precision decimal, datatypeoffset,

binary, varbinary, uniqueidentifier, etc.• Types non supportés: spatial, XML, max

types

• Requêtes DML et DDL supportées– Possibilité de faire évoluer le schéma

de la table

** Space Used = Table space + Index space

0.0

5.0

10.0

15.0

20.0

Space Used in GB (101 million row table)

91% savings


Nouveauté SQL Server 2014: Updatable Columnstore Index

• DML (update, delete, insert) -> Utilisent le delta store

• INSERT Values– Toujours dans le delta store

• DELETE– Opération logique– Donnée effacée physiquement après REBUILD

• UPDATE– DELETE suivi d’un INSERT.

• BULK INSERT– Si batch < 100k, insert dans le delta store, sinon

columnstore

• SELECT – 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.

C1 C2 C3 C5 C6C4

Colu

mn

Stor

e

C2 C3 C5 C6C4

Del

ta (r

ow)

stor

e

tuple mover

C1


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.

démo


DÉMO COLUMN STORE INDEXES


Demo Clustered ColumnStore Indexes

FactInternetSales

Dim Date

Dim Custom

er

Dim Geograph

y

50 Millions de lignes


Demo Clustered ColumnStore Indexes


#mstechdays

LE IN-MEMORY OLTP (HEKATON)


• 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 • In-Memory OLTP for SQL Server 2014

Hekaton: “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 changement5. 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

Les Mythes sur le In-Memory OLTP


• SQL Server In-Memory OLTP est une réponse aux offres de nos compétiteurs

Mythe #1

Réalité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


• In-Memory OLTP c’est comme un DBCC PINTABLE

Mythe #2

Réalité

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.


• In-Memory OLTP est un nouveau produit séparé

Mythe #3

Réalité

In-Memory OLTP complétement intégré à SQL Server 2014


Memory Optimized Data Filegroup Data Filegroup

SQL Server.exe

Memory Optimized Tables & Indexes

TDS Handler and Session Management

Natively Compiled SPs and Schema

Buffer Pool for Tables & Indexes

Client App

Transaction Log

Query Interop

T1

T3

T2

T1

T3

T2

Tables

Indexes

T-SQL Query Execution

T1

T3

T2

Parser, Catalog, Optimize

r

Native Compiler In-mem

OLTP Compone

nt

KeyExisting

SQL Compone

nt

Generated .dll

Non-durable

table

Hekaton Architecture


• On peut passer un application au In-Memory OLTP sans aucun changement

Mythe #4

RéalitéIl y a quelques modifications à faire, au minimum dans le schéma.Modifications plus faciles si on utilise déjà des Stored Procedures


• StorageALTER DATABASE ContosoOLTP ADD FILEGROUP [ContosoOLTP_hk_fs_fg] CONTAINS MEMORY_OPTIMIZED_DATA;ALTER DATABASE ContosoOLTP

ADD FILE (NAME = [ContosoOLTP_fs_dir], FILENAME = 'H:\MOUNTHEAD\DATA\CONTOSOOLTP_FS_DIR') to FILEGROUP [ContosoOLTP_hk_fs_fg];

• TableCREATE 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 procedureCREATE 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 asBEGIN 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

Migration vers Hekaton


• 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

Mythe #5

RéalitéLe In-Memory OLTP est compatible avec les composants HA, incluant AlwaysOnLes données sont résidentes sur disque, et survivent à un crash.On peut aussi travailler avec des tables volatiles


Concurrence d’accès

Multi-version data store

Snapshot-based transaction isolation

No TempDB

Conflict detection to ensure isolation

No deadlocks

No locks, no latches, minimal context switches

No blocking

Multi-version

Optimistic


Hash Indexes

4567

0123

Array of8-byteMemorypointers

Hash index with (bucket_count=8): Fonction de hashing f:• Mape les valeurs aux buckets• Dans le système

Hash mapping:

f(Jean)

f(Jules)f(Laura)

f(Paris)

f(Toulon), f(Nice)

Hash Collisions


Memory Optimized Tables et Indexes

50, ∞ Jean Paris

Timestamps NomPointeurs Ville

Hash index Ville

Hash index Nom

90, ∞ Laura Toulon

f(Jean)

f(Laura)f(Paris)

f(Toulon)



50, ∞ Jean Paris


Hash index Ville

Hash index Nom

T100: INSERT (Jules, Paris)

100, ∞ Jules Paris


f(Jules) f(Paris)




50, ∞ Jean Paris


Hash index Ville

Hash index Nom

T150: DELETE (Laura, Toulon)


90, 150



90, 150 Laura Toulon

50, ∞ Jean Paris


Hash index Ville

Hash index Nom

T200: UPDATE (Jules, Paris) to (Jules, Nice)


200, ∞ Jules Nice

100, 200

f(Nice)

f(Jules)



90, 150 Laura Toulon

50, ∞ Jean Paris


Hash index Ville

Hash index Nom

T250: Garbage collection

100, 200 Jules Paris

200, ∞ Jules Nice

f(Jules)

f(Jean)

f(Nice)

f(Paris)


• Analysis, Migrate and Report Tool

• Configure Management Data Warehouse,

• Configure Data Collection, and run AMR Reports to identify performance hotspots

AMRBEGIN

Is MDW Set up?

Configure Management Data Warehouse

Configure Data Collection

Establish System Performance Baseline Run workload

Run AMR Reports

Migrate

Run Workload and collect performance

metrics

Compare to Baseline and set as new baseline

COMPLETE


• Table Analysis• Usage Analysis• Contention

analysis• Store Procedure

Analysis• Usage Analysis

AMR Report


• 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

Limitations dans SQL 2014 (V1)


• 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

Hekaton en bref

démo


DEMO HEKATON


#mstechdays

CONCLUSION


• 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)

Le In-Memory dans SQL Server


Sessions Data Insights pour les professionnels de l’IThttp://aka.ms/itprosql

Sessions Data Insights pour les décideurs informatiqueshttp://aka.ms/itdmsql

Business Accelerator, un programme sur mesure pour les éditeurs de logicielhttp://aka.ms/isvbusacc

Un client prêt à témoigner ? Une belle histoire à partager ? Un Nokia Lumia à gagner !http://aka.ms/cloudosref

Ressources

http://aka.ms/itprosql

http://aka.ms/itdmsql

http://aka.ms/isvbusacc

http://aka.ms/cloudosref

© 2014 Microsoft Corporation. All rights reserved. Microsoft, Windows, Windows Vista and other product names are or may be registered trademarks and/or trademarks in the U.S. and/or other countries.The information herein is for informational purposes only and represents the current view of Microsoft Corporation as of the date of this presentation. Because Microsoft must respond to changing market conditions, it should not be interpreted to be a commitment on the part of Microsoft, and Microsoft cannot guarantee the accuracy of any information provided after the date of this presentation. MICROSOFT MAKES NO WARRANTIES, EXPRESS, IMPLIED OR STATUTORY, AS TO THE INFORMATION IN THIS PRESENTATION.

Digital is business

Deep Dive Performance , le In-Memory dans SQL Server

Technology

Transcript of Deep Dive Performance , le In-Memory dans SQL Server