[Report] Tout savoir sur In-Memory DB option 12c


memoryVoilà, c’est fait… mardi soir à San Francisco, le PDG d’Oracle, Larry Ellison, a officialisé la sortie de l’option In-Memory DB pour la version Database 12c !

<< Revoir dans son intégralité le lancement officiel de l’option In-Memory DB 12c de Larry Ellison >> 

« Sortir le fauve de sa cage »

Depuis l’annonce de sa sortie pour 2014 (lors du dernier Oracle OpenWorld 2013), cette option a suscité un vif intérêt, ainsi qu’un grand nombre d’espoir et d’interrogation.

Mais Oracle avait bien gardé le secret jusqu’à maintenant et c’est donc juste avant l’été que son PDG a décidé de dévoiler la bête. En effet, après des années de développement et plusieurs mois de béta testing, il devenait important de sortir le fauve de sa cage afin de ne pas laisser la concurrence chasser trop longtemps seule sur le territoire du In-Memory Processing. On pense tout de suite à SQL Server et à SAP HANA. Mais avec la mise sur le marché de cette option Oracle frappe très fort et prend une belle longueur d’avance désormais.

Que les francophones se rassurent, il y aura une séance de rattrapage sur Paris le 18 juin prochain (cliquez ici pour vous inscrire). Pour ceux qui auront la chance d’y assister vous aurez la possibilité de poser toutes vos questions aux nombreux consultants Oracle qui seront présents.

En attendant, faisons un petit retour sur ce qui a été annoncé lors de ce lancement.

  • Génèse du projet

Ce projet est né d’un constat simple : il est aujourd’hui impossible d’exécuter, dans la même base de données (bdd), des requêtes analytiques en temps-réel, sur les données courantes, tout en conservant un historique important, et cela sans impacter les performances transactionnelles !

En effet, les DBA le savent bien, il y a deux utilisations majeures d’une base de données : en mode transactionnel (OLTP) et en mode analytique (BI). Ces deux mondes cohabitent difficilement et les faire fonctionner ensemble a toujours été un vrai casse tête.

Les bdd OLTP se caractérisent par une forte activité transactionnelle temps-réel et constante, ce qui nécessite d’être très rapide sur les ordres DML simples (INSERT, UPDATE et DELETE) et cela implique un faible nombre d’index et très peu de SELECT volumineux.

Quant aux bdd analytiques, elles interrogent de manière complexe, avec de multiples jointures, d’énormes volumes de données historiques, qui sont chargés ponctuellement par de gros batchs (la plupart du temps la nuit tant les traitements sont consommateurs et longs).

  • Des formats de stockage dédiés

Réconcilier ces 2 modes d’utilisation dans une même bdd hybride a toujours été compliqué. Pour palier cette divergence d’approche, on favorise généralement la fonction principale qui nous intéresse le plus (OLTP ou BI) au détriment de la seconde. Très souvent on préfère l’analytique et on ajoute pour cela une multitude d’index complexes sur les grosses tables afin de permettre des SELECT plus rapides.
De fait, dans les grosses bdd, il n’est pas rare de voir des dizaines d’index sur des tables de plusieurs centaines de Go.

Malheureusement, en faisant cela on ralentit le flux OLTP (la mise à jour des indexes étant très couteuse et lente, notamment lors des phases d’Update) et on complexifie surtout les phases de maintenance du DBA. C’est pourquoi on préfère très souvent distribuer les données dans 2, voire plusieurs bdd spécialisées selon le type d’usage souhaité. Mais cela augmente le coût et la complexité de l’architecture globale car ceci implique plus de matériel, des ETL, de la réplication, de la synchronisation, la réécriture de l’application et une multitude de tâches d’exploitation OpEx (sécurité, backup,…).

« Deux mondes incompatibles »

Outre la spécialisation des usages dans des bdd dédiées, on a depuis longtemps identifié le type d’accès idéal à la donnée pour chacun de ces environnements. On parle alors de stockage au format ligne (row format) pour les OLTP et de format colonne (column format) pour l’analytique.

stockage_format

Le format ligne permet de traiter en peu de lignes un maximum de colonnes, il est donc parfait pour travailler de manière unitaire sur un ensemble large de colonnes différentes qui composent l’enregistrement dans une table.

Quant au format colonne, il permet de traiter en peu de colonnes un maximum de lignes, idéal donc pour travailler sur des volumes très importants et pour ramener rapidement un large ensemble de lignes contenues dans la même colonne d’une table.

Cette différence fondamentale de mode de stockage rendait incompatible les 2 mondes dans la même bdd… avant, il fallait choisir et/ou subir !

  • In-Memory DB permet la fusion de ces 2 formats

L’option In-Memory DB va enfin réconcilier ces 2 mondes dans une même bdd Oracle DB 12c !

Le principe est le suivant, actuellement les blocs de données Oracle DB sont stockées sur disque au format ligne et montés en mémoire SGA dans le même format (plus précisément, montés dans le Buffer Cache qui est une zone tampon dédiée aux traitements des données dans la SGA).
Avec cette option, une nouvelle zone mémoire dédiée fait son apparition dans la SGA : la In-Memory Column Store. Vous l’avez deviné, cette zone mémoire va accueillir les données au format colonne.

Désormais, pour une même table, les données disques sont simultanément chargées en mémoire, et donc accessibles en même temps dans les 2 formats (ligne et colonne).

« Il n’y a rien à faire, le moteur choisit lui même le bon format »

La cohérence transactionnelle est assurée dans chaque zone par le moteur Oracle et l’optimiseur de la bdd va choisir automatiquement le mode adéquat pour chaque requête.
Oui, oui, vous avez bien lu, il n’y a rien à faire, le moteur choisit lui même le bon format à votre place !

Ainsi, une requête analytique utilisera les données présentes dans la nouvelle zone mémoire colonne, tandis que les requêtes OLTP continueront à utiliser la zone mémoire ligne traditionnelle.

acces_IMDB

Dés lors, dans une même bdd OLTP on peut faire de l’analytique temps-réel, sur les données courantes et historiques, sans impacter les performances transactionnelles, voire même en les accélérant. On profite désormais du meilleur des 2 mondes !

  • Avantages
    • 50% d’index en moins

Pour les tables que vous déciderez de monter en mémoire au format colonne, l’ensemble des indexes analytiques existants deviendront, de fait, inutiles. Il ne sera donc plus nécessaire de les conserver dans la bdd car seuls les indexes OLTP seront suffisant (PK et Unique notamment). Imaginez donc la quantité d’espace que l’on va pouvoir libérer dans la bdd, allégeant ainsi l’empreinte sur le stockage et la durée des sauvegardes/restaurations. Mais aussi la diminution drastique de la maintenance DBA sur les indexes (réorganisation ou calcul des statistiques).
Ajoutons que, comme les indexes analytiques ne seront plus à mettre à jour, le flux transactionnel va s’en trouver accéléré d’autant !

imdb_index

    • Compression des blocs en mémoire

Le mode colonne stocke, dans un même bloc, des données qui sont de même type, cela permet donc de mieux les compresser à l’intérieur. Oracle annonce un ratio de compression allant de 2 à 20 selon la cardinalité de la donnée compressée. Cela rend la lecture des blocs encore plus rapide et permet d’en accueillir plus en mémoire.

    • Pas d’écriture sur disque

Puisque seulement des ordres SELECT utilisent la zone mémoire au format colonne, il n’y a pas besoin d’écrire de bloc mémoire sur disque et donc il n’y a aucun overhead concernant ce type d’IO.

    • Accélère les jointures

Les jointures simples ou en étoile sont converties en colonne, ce qui les rend 10 fois plus rapides.

    • Des réponses en microsecondes

En exploitant le cache local du CPU et en le combinant avec la compression et le scan des seules colonnes qui nous intéressent, on arrive à lire 2,5 milliards de lignes par seconde et par CPU Core. Bien entendu, ce chiffre est à multiplier par le nombre de CPU Core qui compose votre machine, soit des dizaines, voire des centaines de milliards de lignes scannées par seconde !!!
De plus, dans un environnement RAC, il est possible de paralléliser les traitements sur l’ensemble des nœuds du cluster et ainsi utiliser toute la puissance mémoire/CPU de chacun des nœuds pour aller encore plus vite.

    • Transparent pour les applications

Le moteur Oracle s’occupe de rediriger le traitement des requêtes vers la bonne zone mémoire, ainsi, le code applicatif n’a absolument pas besoin d’être retouché. C’est extrêmement important pour le déploiement de cette technologie qui pourra ainsi être implémentée rapidement en production sans impacter les projets.

    • Une mise en place simple et rapide

Pour le DBA, il lui suffit de définir avec une simple commande, et une fois pour toute, la taille globale initiale de la zone mémoire au format colonne à créer (on pourra bien entendu la retailler à la demande par la suite) et on va y ajouter les tables ou les partitions de table que l’on souhaite dupliquer au format colonne. Là aussi avec une simple commande ALTER sur les tables en question. Et si vous ne souhaitez plus que la table soit en zone mémoire colonne, il suffit juste de la supprimer de la zone avec l’ordre ALTER inverse. Une fois que l’on est sûr d’avoir identifié et activé les bonnes tables ou partitions, il ne reste plus qu’à supprimer les index analytiques qui sont devenus inutiles.

Voilà, c’est tout ! Simple, non ? Aucune migration de données n’est nécessaire.
Seul pré-requis, patcher simplement la DB en version 12.1.0.2 avant.

    • Tolérance aux pannes

Avec la technologie Oracle RAC, on peut décider manuellement de monter les tables dans un ou plusieurs nœuds du cluster afin de faire face à la panne éventuelle d’un nœud.

Avec ExaData, on va avoir la possibilité de demander la duplication automatique des colonnes (mirroring) sur les nœuds du cluster afin de toujours être sûr qu’il y aura un nœud actif qui répondra.

exa_mirroring_inmemory

    • Cerise sur le gâteau

Vous l’avez compris, In-Memory ne fait qu’ajouter une nouvelle zone mémoire colonne à tout ce qui existe déjà. Les données sur disques sont toujours stockées au format ligne comme avant et la zone mémoire au format ligne (Buffer Cache) reste elle aussi inchangée. Ainsi, l’ensemble des technologies Oracle existantes sont 100% compatibles avec cette option : RMAN, FRA, RAC, ASM, DataGuard, GoldenGate, Multitenant, Cloud,… tout fonctionne comme avant et sans aucun changement. Il en est de même pour les applications existantes car rien n’a besoin d’être réécrit ou modifié.
L’option est applicable de suite !

  • Retour d’expérience

De nombreux clients Oracle ont déjà testé en Béta-test cette option sur leurs environnements de production et les résultats sont très impressionnants. A titre d’exemple, voici quelques uns des retours d’expérience qui ont été cités lors de la présentation :

    • Analyse financière avec PeopleSoft
      Sans l’option : 4h15 | Avec l’option : 11,5 sec | 1300 fois plus rapide
    • Gestion des créances avec JD Edwards
      Sans l’option : 4h | Avec l’option : 4 sec | 3500 fois plus rapide
    • Analyse logistique avec e-Business Suite
      Sans l’option : 4h | Avec l’option : 3 min | 76 fois plus rapide
    • Import et nettoyage d’1 million d’enregistrements avec Siebel
      Sans l’option : 2h | Avec l’option : 49 sec | 140 fois plus rapide
    • Clôture comptable avec Fusion Application
      Sans l’option : 10 min | Avec l’option : 3 sec | 210 fois plus rapide
  • Le bouquet final

La présentation s’est terminée par une série de démonstrations effectuées par Juan Loaiza (Senior Vice Président) sur différents environnements afin de montrer toute la puissance et la simplicité de l’option In-Memory DB 12c.

    • Sur un simple serveur 2 sockets
      • 4 millions de lignes, sans index, (équivalent à 1 semaine d’activité) traitées en quelques fractions de secondes
      • Un test similaire a été effectué avec un flux transactionnel simultané de 9 000 insertions par seconde. La durée du traitement est restée inchangée, prouvant ainsi l’absence d’impacts négatifs d’un environnement par rapport à l’autre.imdb_demo_oltp4M
    • Sur un ExaData à 8 nœuds et 14 cellules de stockage
      • 33 milliards de lignes (2 mois d’activité) traitées en quelques fractions de secondes
      • 1 000 milliards de lignes (6 ans d’activité), réparties en tiering sur disques et cartes flash, traitées en 4 secondesimdb_demo_33Mimdb_demo_1T
    • Sur un M6-32 (la Big machine d’Oracle : 32 To RAM et 384 CPU Core)
      • 1 000 milliards de lignes (6 ans d’activité) traitées en quelques fractions de secondesimdb_demo_1TM6

 

On voit à quel point cette technologie peut rendre de très grands services à bon nombre d’utilisateurs d’Oracle DB. Bien sûr on pense d’abord aux DBA de production qui seront ravis d’avoir un tel jouet entre leurs mains, ensuite aux architectes et aux chefs de projets qui vont s’en donner à cœur joie tant les domaines d’applications sont vastes et nombreux. Mais à mon sens, ce sont les métiers qui vont être les grands gagnants de l’implémentation d’une telle fonctionnalité. En effet, jamais le terme d’entreprise temps-réel n’a aussi bien porté son nom et désormais l’agilité et la productivité vont être décuplées pour faire du SI un véritable vecteur de perfomance de l’entreprise.

Tagué:, , ,

3 réflexions sur “[Report] Tout savoir sur In-Memory DB option 12c

  1. VW 13/06/2014 à 09:52 Reply

    Hello Hakim,
    très beau billet.
    Merci
    Vincent W.🙂

    J'aime

  2. GREMEL 19/06/2014 à 14:35 Reply

    Félicitations pour cette présentation.
    Yves G.

    J'aime

  3. VanEyt 02/07/2014 à 22:17 Reply

    Trés bon papier. Je crois avoir lu aussi que la granularité du in-memory store va jusqu’à la colonne. Donc on pourra exclure toutes les colonnes qui n’ont pas d’interêt pour l’analytique, je pense notamment aux libellés et chose de ce genre. A noter que le in-memory store peut être compressé aussi. C’est très important pour les responsables d’infrastructure de minimiser l’empreinte RAM même si son prix tend à diminuer.

    J'aime

Laisser un commentaire

Entrez vos coordonnées ci-dessous ou cliquez sur une icône pour vous connecter:

Logo WordPress.com

Vous commentez à l'aide de votre compte WordPress.com. Déconnexion / Changer )

Image Twitter

Vous commentez à l'aide de votre compte Twitter. Déconnexion / Changer )

Photo Facebook

Vous commentez à l'aide de votre compte Facebook. Déconnexion / Changer )

Photo Google+

Vous commentez à l'aide de votre compte Google+. Déconnexion / Changer )

Connexion à %s

%d blogueurs aiment cette page :