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
Volumétries
grandissantes
Besoin en
analyse de
données
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 Column
Store ?
– 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
CU
Min = Chimay
Max = 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
Volumétries
grandissantes
Besoin en
analyse de
données
Besoin de
rapidité
d’exécution
Structure de
données adaptée
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 de
compression
Rapidité
d’exécution
des requêtes

09/02/2016 18
Volumétries
grandissantes
Besoin en
analyse de
données
Besoin de
rapidité
d’exécution
Structure de
données adaptée
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

– 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

– 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 est
particulié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

• 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

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_ID
FROM CLIENT c, VENTE v
WHERE PAYS=‘UK’
AND v.MONTANT>150
AND C.CL_ID=V.CL_ID
Bloom Filter
CL_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
TEMPS(1/100SECONDE)
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 Cohen
Président EMEA - SAP
Franck Cohen
Président EMEA - SAP
Source : 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

• 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

• 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

• 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’heure
09/02/2016 50

Oracle 12c in memory en action

CONCLUSION
Emmanuel Docquois – Ingénieur Avant Vente
09/02/2016 52

Oracle 12c in memory en action

Contenu connexe

Tendances (20)

En vedette (20)

Similaire à Oracle 12c in memory en action (20)

Oracle 12c in memory en action

Notes de l'éditeur