Oracle 12c : Oracle détaille son approche du In-Memory

Lancée en juin 2013, la version 12c de la base de données d’Oracle mettait en avant une fonctionnalité phare : le « In-Memory ». Une technologie qui consiste à mettre en cache dans la RAM du serveur des données à traiter pour en accélérer drastiquement les traitements.

Avec cette méthode, Oracle répondait à la concurrence de SAP HANA et revendiquait des exécutions de requêtes 100 fois plus rapides par rapport aux SGBD classiques. Sauf que la fonctionnalité n’était pas disponible et qu’il a donc fallu attendre neuf mois pour voir arriver ce module, baptisé « Oracle Database In-Memory Option », et transformer la promesse en réalité.

Pour l’occasion, Andy Mendelsohn, Executive Vice President Oracle Database Server Technologies, était de passage cette semaine à Paris. Il y a décrypté la conception d’Oracle du In-Memory et les différences fondamentales par rapport « au reste du marché » - principalement SAP

Un In-Memory qui fonctionne sans migration de données ni modification des applicatifs

« Le In-Memory est une chose que nous n’avions pas », admet-il d’entrée. « Aujourd’hui, nous l’avons. Nos clients pourront désormais bénéficier de la robustesse et de tous les avantages de la base d’Oracle, et en plus, de cette fonctionnalité. » En clair, il s’agit bien d’un module (payant) optionnel et non d’une mise à jour. Point positif, ce In-Memory ne nécessite pas de migration de données et - Oracle l’assure - il fonctionne « out of the box » avec les applications installées, sans aucune modification.

Première nuance technique que précise Andy Mendelsohn, il s’agit ici de « In Memory Column Databases » (bases de données en colonnes), contrairement à sa base TimesTen qui fait elle-aussi du In-Memory, mais avec des bases en lignes et pour l’embarqué.

 « Ces bases en colonnes sont issues de travaux universitaires qui datent d’une dizaine d’années », se souvient le porte-parole d’Oracle. « Elles sont particulièrement adaptées à l’analytique. Mais peu au transactionnel, contrairement aux bases en lignes. » Or, d’après lui, aucune application n’est entièrement transactionnelle ou entièrement analytique. D’où la nécessité d’avoir une base qui réponde aux besoins des deux mondes.

Une base à la fois en colonnes et en lignes pour ne pas sacrifier le transactionnel au décisionnel

C’est à ce « mix workload » qu’entend répondre Oracle 12c avec son module. L’extension inclut un « Query Optimizer » qui détermine si une requête nécessite l’un ou l’autre type d’outils. «  Aucun de nos compétiteurs ne propose cela, se félicite-t-il,  toutes les autres bases obligent à choisir entre les deux. » Y compris, d’après lui, SAP avec HANA (une base qui mélange pourtant elle aussi traitement en lignes et en colonnes) qui serait donc moins tout-terrain. « Ils (NDR : SAP) ne vous le diront pas parce qu’ils sont très forts en marketing, mais HANA n’accélère pas les ERP et les applications transactionnelles. » Et d’enfoncer le clou sur les bases en colonnes en séance publique : « au contraire, cela peut même ralentir ces applications. »

Pour l’expliquer, Andy Mendelsohn est revenu sur les principes de ces deux types de SGBD. Dans une base en lignes, chaque entrée est composée de x colonnes. Il est facile d’ajouter une ligne, mais analyser la totalité d’un facteur (une colonne) nécessite de scanner la totalité des lignes (la totalité des x colonnes de la totalité des lignes de la base). Un processus très long.

A l’opposé, une base en colonnes permet de ne scanner qu’une colonne (ou seulement les colonnes choisies) de chaque entrée. Les comparaisons et les opérations en sont drastiquement accélérées. Revers de la médaille, ajouter une ligne (processus simple et rapide avec la précédente base) est beaucoup plus long. Or, le transactionnel implique beaucoup d’inputs.

Autre explication avancée, « les processus de transactions sont ralentis par les index de l’analytique ». Pourquoi ? Parce que là où une base OLTP n’aura besoin que de 1 à 3 index pour fonctionner correctement, un processus analytique en exigera entre 10 et 20. Créer une ligne dans une base commune dans un cadre transactionnel demandera donc également de modifier ces 10 à 20 index (et non plus seulement 1 à 3).

Didier Mamma de SAP France ne conteste pas qu’une base en colonnes soit moins adaptée à l’écriture. En revanche, pour lui, « Hasso Plattner (NDR : fondateur de SAP et concepteur de HANA) a analysé les choses plus en profondeur. Il a identifié que les ERP et le transactionnel utilisent beaucoup plus la lecture qu’on ne le croit ». Et de conclure, « il a montré que des bases en colonnes augmentent aussi leurs performances ».

Base « tout à la carte » qui s’adapte à l’existant chez Oracle vs « tout compris » en appliance chez SAP

Autre différence fondamentale entre les deux acteurs : là où HANA traite des données brutes et les met toutes en cache, à l’inverse Oracle propose de ne mettre qu’une partie des données en mémoire. « On peut tout charger si l’on veut, mais cela prend du temps et très souvent cela n’est pas nécessaire dans un contexte métier », avance Andy Mendelsohn. « Vous n’avez souvent besoin que de travailler sur les six ou douze derniers mois, pas sur la totalité d’un dataWarehouse. » Au DBA de choisir quelles tables, partitions de tables ou quels champs mettre en mémoire. Ce choix jumelé à celui de la méthode de compression détermine une taille totale de DRAM nécessaire. Et donc l’achat ou non de mémoire supplémentaire.

Andy Mendelsohn souligne sur ce point qu’il est parfaitement possible de distribuer la mémoire sur la RAM de plusieurs serveurs et de faire du Mirroring (pour prévenir les cas de sinistres) avec Real Application Cluster. Une méthode qu’utilise aujourd’hui Yahoo.

Sous couvert d’une éventuelle augmentation de la RAM, « Oracle Database In-Memory Option » a été conçue pour être compatible avec toutes les plates-formes hardwares actuelles et tous les OS. « Contrairement à HANA qui est certifié uniquement pour quelques appliances, dont nos clients nous disent qu’elles sont visiblement très couteuses », tacle le dirigeant d’Oracle.

Effectivement, chez SAP, HANA vise à remplacer les bases de données installées (notamment Oracle) et permet de simplifier l’infrastructure. A condition d’en changer. L’éditeur allemand explique ainsi que si une entreprise possède 1 Téra de données, le passage à HANA lui permettrait de ne conserver en tout et pour tout que 200 Go à 400 Go de stockage – grâce à la compression et grâce à l’accès aux informations brutes qui affranchit des pré-modélisations, des Datamarts et des étapes intermédiaires du traitement des requêtes. Là où Oracle, donc, augmentera la RAM de l’existant.

Dans la guerre qui oppose les deux géants, cette différence fait dire au PDG de SAP, Bill McDermott, que le In-Memory de Oracle est « ajouté à sa base comme on ajoute un side-car à une moto ». Comprendre, ce n’est pas le même niveau de technologie puisqu’elle n’est pas native chez l’Américain. Chez Oracle, l’objection fait sourire. Elle serait une manière très négative de présenter une stratégie positive : la modularité et le choix de faire évoluer l’existant plutôt que de le changer intégralement.

Des gains de vitesse d’un facteur 9 à 80 selon les bêta-testeurs

Côté performances, Oracle revendique toujours des gains de rapidité d’un facteur 100 en analytique mais aussi, en « effet de bord », des temps de réponses divisés par deux en mode OLTP. L’explication technique tient au fait que son module In-Memory supprime les index et les remplace par une base en colonnes et en mémoire. « Nous avons abandonné les index de l’analytique pour accélérer le transactionnel », confirme Andy Mendelsohn.

Dans la réalité, les gains constatés par les bêtas testeurs sont curieusement plus importants en utilisation transactionnelle que ceux affichés par Oracle. En France, Schneider Electric a par exemple constaté des résultats neuf fois plus rapides.

En analytique pure en revanche, et en fonction des compressions choisies, les résultats des traitements et requêtes sont « seulement » 20 à 80 fois plus rapides. François Bermond, responsable Data & Analytics de l’industriel, modère ce « seulement » avec une comparaison d’ordres de grandeurs. « Cela reste la différence entre la vitesse d’un coureur de 100 mètres et celle d’un avion furtif supersonique », resitue-t-il.

« Oracle Database In-Memory Option » sera disponible en juillet. L’éditeur ne donne pas de prix mais assure que la tarification sera celle généralement pratiquée avec ses options.