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 ».

Option in-memory d'Oracle
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.

Digora
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.