L'option in-memory d'Oracle sera disponible en juillet pour la version 12c de sa base de données, mais on ne sait toujours pas à quel prix. L'éditeur américain met en avant sa capacité à accélérer les requêtes analytiques par un facteur 100, sur les datawarehouses comme sur les bases OLTP, et de rendre deux fois plus rapides les traitements transactionnels (insertion de données dans les tables). L'option a déjà été testée par différents clients et partenaires dont, en France, le groupe Schneider Electric et la SSII Digora qui ont livré leurs premières impressions la semaine dernière lors du passage à Paris d'Andy Mendelsohn, responsable des technologies serveur pour Oracle. Une semaine après le lancement officiel, ce dernier est venu rappeler les signes distinctifs de cette offre qui monte les données en mémoire pour doper la vitesse de traitement, mais qui arrive sur le marché après celles de ses concurrents. SAP, en particulier, prêche le in-memory depuis plusieurs années avec HANA, qu'il a d'abord exploité sur le décisionnel puis sur ses applications transactionnelles. Microsoft a lui aussi d'abord livré des capacités in-memory pour l'analytique, puis sur l'OLTP avec SQL Server 2014 en avril.

Avec la version 12c, sortie l'an dernier, Oracle avait déjà réarchitecturé de façon importante sa base de données pour lui ajouter les fonctions « multitenant » que réclamaient les applications cloud. Depuis 35 ans, le fournisseur transforme son produit phare en fonction des évolutions technologiques, a pointé Andy Mendelsohn. Avec le in-memory, la 1ère carte qu'Oracle choisit d'abattre face à la concurrence, c'est donc sans surprise son expérience sur les bases de données qui lui permet de capitaliser sur les fonctionnalités et la robustesse éprouvées du produit, en incluant des produits comme Data Guard et Golden Gate (protection et disponibilité des données, réplication), a pointé Andy Mendelsohn. Autre argument avancé, la capacité d'exploiter l'option in-memory sans modifier les applications qui tournent actuellement sur des bases Oracle. Cette facilité d'accès est corroborée par les participants du programme bêta comme Rittman Mead, Digora et Schneider Electric. Par ailleurs, l'option n'est pas couplée à une solution matérielle particulière (comme c'est le cas avec HANA de SAP) et peut s'installer sur n'importe quelle plateforme exploitant la Database 12c, souligne encore le responsable des technologies serveurs. 

Stockage en lignes et en colonnes synchronisés

Oracle a pris en charge le in-memory d'une façon particulière. Son option ajoute à Database 12c un mode de stockage en colonnes, monté en mémoire vive, tout en conservant le mode de stockage en lignes utilisé par les millions d'applications déjà développées pour sa base, explique l'éditeur californien. L'option exploite les deux formats en mémoire, utilisant de façon transparente l'un ou l'autre en fonction du type d'opérations à effectuer, tout en maintenant la synchronisation entre les deux. Depuis plus de 30 ans, le stockage en colonnes est connu pour optimiser les requêtes analytiques, a rappelé M. Mendelsohn en réexpliquant par le menu l'intérêt de chacun des formats. En mode colonne, faire par exemple du reporting sur les ventes d'un produit par pays sur une période donnée nécessite de balayer seulement quelque colonnes dans une table et de le faire très vite.

A l'inverse, le stockage en lignes est adapté aux applications transactionnelles. Typiquement, l'insertion d'un bon de commande, dans une application de gestion des ventes, s'effectue de façon linéaire et continue sur une ligne. Les différents éléments de la commande (nom du produit, montant, etc.) sont répartis entre les colonnes avant l'écriture sur disque, effectuée en une seule entrée/sortie. « Le stockage en ligne a été conçu pour ce genre de transaction et si vous ne faites que du transactionnel, vous n'avez pas besoin de stockage en colonnes », a souligné M. Mendelsohn. « Mais la plupart des clients effectuent à la fois du transactionnel et de l'analytique et nous ne voulons pas de compromis. Nous leur disons, faites les deux, créez un stockage en ligne et un stockage en colonnes parfaitement synchronisés et quand la requête SQL arrive, le query optimizer (de la base Oracle) va déterminer la meilleure façon de l'éxécuter : sur les données stockées en ligne ou bien sur celles en colonnes, les deux formats étant actifs en même temps en mémoire ». Par ailleurs, les mécanismes de restauration des données et de haute disponibilité de la base 12c ne changent pas. 

On choisit les tables qui montent en mémoire

« Il peut y avoir dans votre base des tables qui seront purement exploitées dans un mode transactionnel, auquel cas, vous n'avez pas besoin de créer pour ces tables un stockage en colonnes », a encore précisé M. Mendelsohn. On choisit les tables que l'on veut mettre en mémoire (NDLA : avec les fonctions in-memory OLTP de SQL Server 2014, Microsoft demande aussi de sélectionner les tables à monter en mémoire). « Si vous avez un datawarehouse, vous pouvez partitionner vos données pour  décider par exemple de ne mettre en mémoire que les six derniers mois ou la partition la plus active », a expliqué le responsable des technologies serveur d'Oracle. « Notre architecture a été conçue pour des usages très larges. On peut exploiter de très très gros datawarehouses et ne pas vouloir tout mettre en mémoire ou bien des bases plus petites et tout monter en mémoire ». Différents niveaux de compression sont également proposés pour les données. On ajuste ces niveaux en fonction des performances que l'on veut obtenir, a par la suite exposé François Bermond, responsable des référentiels de données et de la BI pour le groupe Schneider Electric.

[[page]]


Sur les disques, la représentation de la base Oracle n'est pas changée, elle reste identique à celle utilisée avec la version 11g de Database, a précisé M. Mendelsohn. « Donc, lorsque vous passez à la 12c, vous n'avez pas à migrer vos données, vous installez le logiciel et vous pouvez démarrer ». Par ailleurs, l'option in-memory met en oeuvre différents algorithmes pour balayer très rapidement la mémoire. Elle n'accède par exemple qu'aux colonnes requises par une requête en les traitant directement sans avoir à les décompresser avant. Elle peut aussi recourir aux instructions vecteurs (ou SIMD, single instruction for multiple data values) des processeurs pour traiter les valeurs de plusieurs colonnes dans un seul cycle d'horloge, ce qui permet de balayer des milliards de lignes de données par seconde et par coeur.

L'abandon des index additionnels accélère l'OLTP

Ce qu'Oracle met par ailleurs en avant, lorsqu'une entreprise combine sur la même base des traitements OLTP et analytiques, c'est l'accélération du transactionnel par un facteur 2 grâce au stockage en colonnes de l'option in-memory. Ce mode permet en effet de se passer des nombreux index additionnels habituellement mis en place pour optimiser les requêtes analytiques et faire du reporting. « Il s'en crée couramment 20, voire 30 qu'il faut maintenir à chaque insertion de ligne », rappelle M. Mendelsohn. Avec l'option in-memory, on s'en tient aux index fixant les clés primaires et étrangères indispensables pour maintenir les contraintes d'intégrité sur les données de la base. « C'est le secret pour accélérer le transactionnel en cas de traitements mixtes (OLTP et décisionnel), on laisse tomber les index créés pour générer le reporting dont on n'a plus besoin avec le balayage rapide du stockage en colonnes ».


L'OLTP est ralenti par les index créés pour le décisionnel.

La société Digora, intégrateur d'Oracle depuis de nombreuses années, fait partie du programme bêta de la version 12c. Après avoir creusé la partie multitenant, elle a commencé à tester l'option in-memory. La SSII construit et installe quelques centaines de plateformes par an et en exploite plusieurs milliers au quotidien. « Optimiser une base relationnelle, c'est ce que nous faisons chaque jour auprès de nos clients", a exposé Gilles Knoery, directeur général de Digora, témoignant lors de la conférence d'Oracle la semaine dernière. « Nous intervenons énormément sur les index, nous les ajoutons, les positionnons et il est vrai que cela représente une partie du ralentissement que l'on peut observer dans certaines applications transactionnelles. Mettre en oeuvre une base de données colonnes ne règle pas tout, bien sûr, il y a des avantages et des inconvénients, mais l'approche choisie par Oracle, qui à ma connaissance est unique, me semble révolutionnaire ».

Un préalable incontournable : la migration vers 12c

Digora a exposé les résultats de ses tout premiers tests. Très simples, ceux-ci ont porté sur les dix plus grosses requêtes du benchmark TPC-H (établi par le TPC pour éprouver les applications décisionnelles, ce test décrit 22 modèles de requêtes). La SSII les a fait tourner en séquence dans un environnement mono-utilisateur et constaté des gains impressionnants, a indiqué Gilles Knoery en mettant notamment en avant la requête 21, l'une des plus complexes du benchmark (*), qui s'est exécuté 22 fois plus vite avec l'option in-memory.


Selon les tests de Digora, les requêtes décisionnelles s'exécutent jusqu'à 55 fois plus rapidement. (agrandir l'image).

Sur le terrain, au-delà du pur décisionnel, « il y a vraiment de nouveaux horizons qui s'ouvrent », estime le DG de Digora dont de nombreux clients utilisent les solutions ERP d'Oracle. « Si on peut accéder directement à un schéma OLTP pour faire ses rapports, ça change la donne », pointe-t-il en citant en exemple l'un des clients de la SSII, dans le secteur du retail, qui calcule l'approvisionnement pour ses magasins (quelques centaines en Europe). Celui-ci pourrait passer d'un calcul tous les jours à un toutes les heures pour s'approcher du temps réel. 

« L'activation du in-memory est très simple, c'est une commande à passer », résume Gilles Knoery. On doit ensuite enlever certains index et, en fonction de la mémoire dont on dispose, choisir les tables à y monter, « voire les colonnes », la granularité étant assez fine, précise le DG. Pour accompagner ce choix, Oracle propose, dans les packs diagnostic d'Enterprise Manager, un assistant qui aide l'administrateur à sélectionner les objets à monter en mémoire. On décide aussi du type de compression associé aux colonnes. « Il y a quelques choix qui peuvent se faire petit à petit. Ce qui nous a paru intéressant avec cette approche, c'est que l'on n'est pas obligé de faire un big bang, on peut y aller très progressivement en fonction de son architecture et de son application », a insisté Gilles Knoery. Une approche simple, donc, mais qui nécessite de passer à la version 12c de la base de données d'Oracle. « Le plus long chemin à parcourir reste donc cette migration », rappelle le DG de Digora, migration qui, par ailleurs, n'aurait jamais été aussi facile selon lui.

(*) La requête 21 du TCP-H identifie les fournisseurs qui n'ont pas pu livrer les pièces requises dans les temps impartis dans le cadre d'une commande impliquant de multiples fournisseurs situés dans différents pays.