oracle 12c in memory en action

Oracle 12c In Memory en action

Laurent Léturgez – Techsys

12 Novembre 2014

1

Oracle 12c In Memory

• Agenda

– Structure de données

– Opérations de chargement et de compression

– Algorithmes et optimisations

– Quelques résultats

– RAC, Multitenant, Exadata

– La concurrence

– Etude de ROI

09/02/2016 2


09/02/2016 3

Contexte :

- Base d’historique des ventes- Deux schémas de 15Go environ

- Schéma 1 (TPCH_PART) : Fonctionnement classique- Schéma 2 (TPCHIM_PART) : Fonctionnement in Memory

- Exécution de deux requêtes analytiques dans les deux schémas


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 4


09/02/2016 5

Volumétries grandissantes

Besoin en analyse de données

Besoin de rapidité

d’exécution


09/02/2016 6



Besoin de rapidité

d’exécution

Structure de données adaptée


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 7


• Quoi de neuf avec Oracle 12c In Memory ColumnStore ?

– Une nouvelle zone mémoire: « in Memory column store »

– Un nouveau format : les données sont organisées en colonne dans cette zone mémoire

– Le format en ligne est conservé

09/02/2016 8


• In Memory column store : paramétrage

– Configuré en SGA par le paramètre INMEMORY_SIZE (mini 100Mo)

– Ce n’est pas un cache mais un « magasin » … donc pas d’algorithme de vieillissement (LRU/MRU)

09/02/2016 9


• In Memory column store : Constitution

• Pool IMCU : In Memory Compression Unit

– Contient les unités de compression (CU) : Données formatées en colonne

• Pool SMU

– Stocke les Snapshot Metadata Unit (Equivalent des undo pour l’IM)

09/02/2016 10


• L’IMCU structure de données centrale

– Unité d’allocation pour le stockage des données d’une colonne

– Chaque colonne est stockée dans un espace contigüe séparé des autres colonnes

09/02/2016 11


• L’IMCU structure de données centrale

09/02/2016 12

Marque

Karmeliet

Chimay

Chimay

Duvel

Chimay

Duvel

Westmalle

Duvel

Karmeliet

Clé Valeur

0 Chimay

1 Duvel

2 Karmeliet

3 Wesmalle

CUMin = ChimayMax = Westmalle

2

0

0

1

0

1

3

1

2

Dictionnaire :


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 13


• Provisionnement du pool In Memory

• Montée d’une table dans le pool In Memory

09/02/2016 14

SQL> ALTER SYSTEM SET INMEMORY_SIZE=10G SCOPE=SPFILE;

SQL> SHUTDOWN IMMEDIATE

SQL> STARTUP

SQL> ALTER TABLE SALES INMEMORY;

SQL> ALTER TABLE SALES INMEMORY (PRODUCT_ID);

SQL> ALTER TABLE SALES NO INMEMORY;

SQL> ALTER TABLE SALES

2 > MODIFY PARTITION SALES_Q2_1998 INMEMORY;


• Priorité de montée en mémoire

– NONE < LOW < MEDIUM < HIGH < CRITICAL

– Détermine comment sont montées les colonnes en mémoire• NONE (Défaut) : montée lors du premier accès

• CRITICAL : montée immédiate ET au démarrage d’instance

09/02/2016 15

SQL> ALTER TABLE CUSTOMER INMEMORY PRIORITY CRITICAL;

SQL> ALTER TABLE CUSTOMER INMEMORY PRIORITY NONE;


09/02/2016 16



Besoin de rapidité

d’exécution


Compression des données


• Compression

– Objectif : réduire la volumétrie des données en mémoire

– Format IMCU adapté à une compression efficace

– Différents niveaux• DML

• QUERY LOW (défaut)

• QUERY HIGH

• CAPACITY LOW

• CAPACITY HIGH

09/02/2016 17

SQL> ALTER TABLE CUSTOMER INMEMORY MEMCOMPRESS FOR QUERY HIGH;

SQL> ALTER TABLE ORDERS INMEMORY MEMCOMPRESS FOR DML;

Taux decompression

Rapiditéd’exécution

des requêtes


09/02/2016 18



Besoin de rapidité

d’exécution


Compression des données

Algorithmes adaptés


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 19


• Algorithmes et optimisations

–Objectifs

• Réduire les volumes traités (filtres)

• Réduire le nombre d’opérations (traitements à plusieurs, utilisation du format adéquat)

• Limiter l’impact des volumes sur les traitements (optimisation des jointures, des opérations d’agrégation)

09/02/2016 20


• Algorithmes et optimisations– Utilisation du format adéquat

09/02/2016 21

• Transactionnel et analytique en même temps– Les traitements OLTP tirent bénéfice de l’organisation en lignes

– Les traitements analytiques tirent bénéfice de l’organisation en colonnes

CBO


• Algorithmes et optimisations– Réduire le nombre d’opérations

09/02/2016 22

Suppression des index analytiques (Bitmap)

Optimisation par le format de l’IMCU qui intègre la valeur minimale et maximale


• Si une transaction est enregistrée sur le buffer cache

– le pool IM est maintenu consistant par le Transaction Manager

– L’image avant est maintenue dans le pool IM (SMU)

– La lecture consistante est gérée via le SCN … comme auparavant

– La transaction est enregistrée dans les redo log … comme auparavant

09/02/2016 23


• Traitement à plusieurs + filtrage

• Opérations SIMD (Single Instruction Multiple Data)

– Instructions CPU non spécifiques à Oracle

– Disponibles chez Intel dans les jeux d’instructions SSE (SSE, SSE2, SSE3, SSE4), AVX, AVX2 et AVX-512

– Disponibles sur Power PC, Sparc (VIS & VIS2)

– Utilisation de registres vectoriels

– Permet de traiter plusieurs données en une seule instruction

09/02/2016 24


• Opérations SIMD

– Registre de 128 octets (8 x 16 octets)

– 1024 opérations en mode scalaire = 128 op. en SIMD

09/02/2016 25

Le format d’IMCU estparticuliérement adapté à

ces opérations


• Opérations SIMD

– Les nouveaux processeurs Intel Xeon E5-V3 intégreront les instructions AVX-512 avec des registres de 512 octets

– Références• http://www.intel.com/content/dam/www/public/us/en/documents/white-

papers/performance-xeon-e5-v3-advanced-vector-extensions-paper.pdf

• https://software.intel.com/sites/default/files/m/d/4/1/d/8/Intro_to_Intel_AVX.pdf

09/02/2016 26

http://www.intel.com/content/dam/www/public/us/en/documents/white-papers/performance-xeon-e5-v3-advanced-vector-extensions-paper.pdf

https://software.intel.com/sites/default/files/m/d/4/1/d/8/Intro_to_Intel_AVX.pdf


• Filtrage et optimisation des jointures

• Filtre de Bloom

– Structure de données probabiliste (tableau de bits)

– Permet d’affirmer :• Avec certitude, qu’une valeur ne fait pas partie d’un jeu de

données

• Sans certitude, qu’une valeur fait partie d’un jeu de données (faux positifs qui diminuent avec la taille du jeu de données)

09/02/2016 27

Plus d’information sur la structure - http://antognini.ch/papers/BloomFilters20080620.pdf

- http://fr.wikipedia.org/wiki/Filtre_de_Bloom

http://antognini.ch/papers/BloomFilters20080620.pdf

http://fr.wikipedia.org/wiki/Filtre_de_Bloom


09/02/2016 28

• Filtres de bloom

– Utilisés depuis Oracle 10g notamment :

• Partition Pruning

• Optimisation des jointures par HASH

• Smart Scan Exadata (Elimination des données sur le storage server)


09/02/2016 29

• Filtres de bloom sur Oracle 12c In Memory– Optimisation des jointures en utilisant la structure de données IMCU

et les instructions SIMD

CL_ID NOM PAYS

1 Dupont FR

2 Gilmour UK

3 Martin FR

4 Schultz DE

5 Durand FR

6 Waters UK

7 Mason UK

8 Wright UK

9 Lindemann DE

10 Kruspe DE

CL_ID V_ID MONTANT

1 1 150

2 2 300

9 3 10

8 4 350

2 5 180

7 6 654

4 7 1524

4 8 354

9 9 136

10 5 789

…/… …/… …/…

SELECT c.NOM, v.V_IDFROM CLIENT c, VENTE vWHERE PAYS=‘UK’ AND v.MONTANT>150AND C.CL_ID=V.CL_ID

Bloom FilterCL_ID in 2,6,7,8

HASH JOIN

4 Lignes 4 Lignes


• Optimisation des agrégations

• Transformation par double vecteur de clé

– Optimiser les agrégations de données (GROUP BY) en tirant partie du format en colonne (VECTEUR)

– Transformation opérée par le CBO

– Optimisation des requêtes analytiques avec le format en colonne

09/02/2016 30


• Transformation par double vecteur de clé

09/02/2016 31

MAG_ID LIEU

EN001 Englos

LE001 Leers

LE002 Lens

SE001 Seclin

V2001 V2

…/… …/…

PR_ID NOM

CHI1 Chimay

DUV1 Duvel

GRI1 Grimbergen

KAR1 Karmeliet

KWA1 Kwak

LEF1 Leffe

WES1 Westmalle

MAG_ID

PR_ID MONTANT

SE001 GRI1 150

SE001 DUV1 300

LE002 KWA1 10

SE001 LEF1 350

V2001 WES1 180

LE001 GRI1 654

SE001 WES1 1524

EN001 KAR1 354

LE001 CHI1 136

V2001 WES1 789

…/… …/… …/…

0 3 1 2 4 5

1 0 2 4 5 6 3

CHI1 DUV1 GRI1 KAR1 KWA1 LEF1 WES1

EN001

LE001

LE002

SE001 150 1524

V2001 180 789

1- Création d’un vecteur de clés sur PR_ID

1- Création d’un vecteur de clés sur MAG_ID

2- Applications des vecteurs de clés(prédicat de jointure)

3 - Création d’un accumulateur des données IM(à la volée)

4 – Calcul des agrégats


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 32


• Contexte #1– Base d’environ 15Go

– Oracle Enterprise Linux 7 : 4 vCPU

– Extensions ssse3 (SIMD)

– Charge de type TPC-H : historique des ventes

• 22 requêtes analytiques

• Résultats exprimés en QphH (Queries per hour)

– Passe 1 : SGA : 22Go et INMEMORY_SIZE : 0 (Buffer Cache : 20Go), PGA : 5Go

– Passe 2 : SGA : 22Go et INMEMORY_SIZE : 10Go (Buffer Cache : 10Go) sans données montées en pool IM , PGA : 5Go.

– Passe 3 : SGA : 22Go et INMEMORY_SIZE : 10Go (Buffer Cache : 10Go) avec données montées (Compression QUERY HIGH), PGA : 5Go.

09/02/2016 33


09/02/2016 34

0

5000

10000

15000

20000

25000

30000

R1 R2 R3 R4 R5 R6 R7 R8 R9 R10 R11 R12 R13 R14 R15 R16 R17 R18 R19 R20 R21 R22

TEM

PS

(1/1

00

SEC

ON

DE)

REQUETE

Comparaison In Memory serveur local (Elasped time)

TPCH@10 BC 20Go - T2 TPCH@10 BC 10Go - T2 TPCH@10 IM 10Go - T2


• Contexte #2– Base d’environ 50 Go

– Instance EC2 Amazon : 8 vCPU sous Redhat EL 7

– Extensions AVX

– Charge de type TPC-H : historique des ventes

• 22 requêtes analytiques

• Résultats exprimés en en QphH (Queries per hour)

– Passe 1 : SGA : 55Go et INMEMORY_SIZE : 22,5 Go (Buffer Cache : 10Go) sans données montées en pool IM, PGA : 5Go.

– Passe 2 : SGA : 55Go et INMEMORY_SIZE : 22,5 Go (Buffer Cache : 10Go) avec données montées (Compression QUERY HIGH), PGA : 5Go.

09/02/2016 35


09/02/2016 36

0

10000

20000

30000

40000

50000

60000

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22

Comparaison In Memory Amazon EC2 (Elasped time)

TPCH@30 BC (AWS 55Go SGA + 22,5Go IM) TPCH@30 IM (AWS 55Go SGA + 22,5Go IM)


• Résultats

09/02/2016 37


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 38


• RAC

– Chaque nœud dispose de son pool IM

– Les objets sont automatiquement distribués sur tous les nœuds

– La distribution est gérée au niveau segment (TABLE, PARTITION, SOUS PARTITION)

– Les requêtes peuvent être parallélisées sur tous les nœuds pour obtenir des données locales

09/02/2016 39

SQL> ALTER TABLE CUSTOMER INMEMORY DISTRIBUTE AUTO;

SQL> ALTER TABLE SALES INMEMORY DISTRIBUTE BY PARTITION;


• Multitenant

– Par défaut, les pluggable databases (PDB) héritent de la configuration du conteneur root

– La taille du pool IM est configurable par PDB

– Le surprovisionnement est possible

09/02/2016 40


• Ai-je encore besoin de mon Exadata ?

– Exadata étend les données analytiques au cache Flash et aux disques de l’Exadata

– Bénéfice du Smart Scan

– Sur Exadata les IMCU sont copiés sur les autres computes nodes afin d’assurer la tolérance de panne

09/02/2016 41

In Memory ne remplace pas Exadata, il en augmente

la puissance


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 42


• Combien ça coûte ?– Option de l’Enterprise Edition

– 23 000$ / CPU Oracle (2 cores Intel) soit environ 18400€

… non négocié par votre partenaire

• Vous trouvez ça cher ?

• Qui a dit ? : « Nous reconnaissons que notre technologie est plus chère qu’Oracle »

• Qui a dit ? : « Nous assumons n’accorder aucune réduction à nos produits, contrairement aux usages en France »

09/02/2016 43

Franck CohenPrésident EMEA - SAP

Franck CohenPrésident EMEA - SAP

Source : http://www.silicon.fr/usf-sap-hana-trop-cher-89969.html

http://www.silicon.fr/usf-sap-hana-trop-cher-89969.html


• SAP Hana– Nécessite une appliance dédiée supportée par HANA (Dell, IBM etc.)

– Appliances limitées par la DRAM (http://scn.sap.com/docs/DOC-

52522#jive_content_id_Supported_Hardware_Platforms_RHEL_for_SAP_HANA_Single_Node_ )

– SAP HANA utilise deux caches (lignes et colonnes)

– Les opérations de fusions des données de caches (automatiques) peuvent s’avérer problématiques lors de forte activité transactionnelle (http://scn.sap.com/community/developer-center/hana/blog/2014/06/08/oltp-performace-tunning-of-column-table-in-sap-hana)

“…/…

Two segments of data in different store format will be processed and the calculator always switches between column engine and row engine, which results in bad performance. We recommend doing a manual merge when data in Delta area is large enough or after executing sequences of transactions.

…/…”

– Nécessité de réécrire les applications et revoir les middleware

09/02/2016 44

http://scn.sap.com/docs/DOC-52522#jive_content_id_Supported_Hardware_Platforms_RHEL_for_SAP_HANA_Single_Node_

http://scn.sap.com/community/developer-center/hana/blog/2014/06/08/oltp-performace-tunning-of-column-table-in-sap-hana


• SAP Hana

– Coûts liés à l’OPEX : nouvelle équipe, formation du personnel, nouvelles procédures etc.

– Coûts liés au CAPEX : nouveau hardware, nouveaux logiciels

– Haute disponibilité via cluster « Shared Nothing »• Réplication du stockage et des systèmes

• Architecture complexe – Serveur de noms MASTER ou SLAVE : la topologie du cluster

– Serveur d’indexation WORKER ou STANDBY : contient les datastores et traite l’information

– Serveur de statistiques : collecte les informations de statut, performance et consommation ressources

• Rôle et nombre de serveurs difficilement interopérables09/02/2016 45


• SQL Server 2014 : OLTP In Memory Optimization

– Optimisation pour l’OLTP

– Pool In Memory limité à 250 Go (http://msdn.microsoft.com/en-

us/library/dn170449.aspx)

– De nombreuses limitations dans la gestion des transactions sur les tables InMemory (cf. http://msdn.microsoft.com/en-

us/library/dn133169.aspx, partie Limitations)

• Nécessité de réécrire une partie du code

09/02/2016 46

http://msdn.microsoft.com/en-us/library/dn170449.aspx

http://msdn.microsoft.com/en-us/library/dn133169.aspx


• IBM DB2 10.5 With BLU Acceleration

- Les tables sont organisées en ligne OU en colonne

- L’utilisation colonne + ligne (shadow tables) utilise un mécanisme de réplication basé sur IBM InfoSphere CDC (Réplication)

- Solution complexe à mettre en œuvre

- Solution nécessitant de nombreux produits (Information Server, Replication Server, Access Server, et Management Console)

- Utilise un stockage sur SSD mais pas en DRAM

09/02/2016 47


• Agenda






– La concurrence

– Etude de ROI

09/02/2016 48


• ROI : Contexte – Application Oracle déjà en place sur EE + Partitionnement

– Estimation de coût en €/QphH

– Achat de 4 CPUs In Memory (8 cores Intel).

– Base de travail : test sur EC2 Amazon (plus représentatif)

– Investissement :

• Licences : 4 x 18 400€ = 73600 €

• Prestation d’accompagnement (5 à 10j) : 9000€

• 0 Formation, 0 DBA en plus

09/02/2016 49

Economie de : 201,84 € par QphH

Amortissement ≈ 409j ≈ 1,1 année

QphH@30g€/QphH

(Base de location AWS : 17500€/3ans)

TPCH@30 BC (AWS EC2) 61,06 286,60

TPCH@30 IM (AWS EC2) 206,47 84,76

mailto:QphH@30g

mailto:TPCH@10 IM 10Go (1ere passe)

mailto:TPCH@10 IM 10Go


• Cas d’utilisation

– Batch de calcul des approvisionnements magasins• Intégration des données de Stock

• Intégration de l’historique des ventes

• Intégration des offres promotionnelles

– Allongement de la durée (Criticité de fin de traitements)

– Problème dans l’approvisionnement des magasins

– Avec In Memory column Store• Le batch est réduit de 3h

• Les colis partent à temps

• Les magasins sont approvisionnés à l’heure09/02/2016 50

CONCLUSION

Emmanuel Docquois – Ingénieur Avant Vente

09/02/2016 52

@techsys_fr

oracle 12c in memory en action

Data & Analytics