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.