Openworld 2013 : Oracle met le cap sur l’In-Memory

Visiblement dopé par les deux victoires dans la journée du bâteau Oracle face aux kiwis de New Zealand dans les régates de l'America's Cup, c’est un Larry Ellison conquérant qui s’est présenté devant les 60 000 participants d’Openworld 2013, la conférence annuelle de la firme qui se tient comme chaque année au Moscone Center à San Francisco. À l’occasion de son keynote d’ouverture, ce dimanche 22 septembre, le patron d’Oracle a notamment concentré ses annonces sur la riposte d’Oracle à l’offensive in-memory de SAP avec Hana.

Des performances dopées aussi bien en analytique qu'en transactionnel

Larry Ellison a ainsi dévoilé la nouvelle option In-Memory de la base de données Oracle 12c ainsi qu’un nouveau système SPARC massif optimisé pour la base. La promesse d’Oracle 12c In-Memory est simple, selon Ellison : en modifiant quelques paramètres et en exécutant le moteur en mémoire, un client Oracle peut accélérer ses requêtes SQL par un facteur de 100 et doubler la performance de la base en transactionnel. « Nous voulions que les améliorations apportées par l’In-Memory portent aussi bien sur les aspects datawarehouse que sur le transactionnel », a ainsi expliqué Ellison.

Le patron d’Oracle s’est alors lancé dans un cours magistral sur le fonctionnement des SGBD afin d’expliquer à l’audience comment Oracle 12c fonctionne. Ellison a souligné que les tables de bases de données sont organisées en ligne depuis le début car cette organisation spatiale est bien adaptée à un usage transactionnel. Il a aussi souligné la montée en puissance du stockage de données en colonnes pour les applications analytiques et le Big Data. « L’idée d’une organisation des données en colonnes est de doper les performances des requêtes sur des jeux de données où il y a peu de colonnes mais beaucoup de données ».

Avec l'option In-Memory, Oracle 12 stocke chaque table sous deux formats, ligne et colonne.

Oracle a donc décidé de combiner les deux modèles pour son implémentation In-Memory. La nouvelle option en mémoire d’Oracle 12c stocke ainsi à la fois les données en colonnes et en lignes. « Le magasin de données en colonnes est 100 % en colonnes. Tout est In-Memory, très compressé et il n’y a pas de log de transactions. Donc très peu d’overhead pour maintenir la table en colonne », a souligné Ellison - il n'a au passage pas précisé si cette duplication des tables en mémoire se traduisait aussi par une duplication sur disque, auquel cas il sera sans doute intéressant de disposer d'un système de stockage Oracle à même de tirer parti de la compression en colonnes. Le résultat : une aptitude à traiter des données à une vitesse infernale (« ungodly », selon les propres termes d’Ellison). Selon le patron d’Oracle, la nouvelle base peut parcourir des milliards de lignes par seconde et par cœur CPU. Les jointures entre tables se font aussi 10 fois plus rapidement qu’avec la base traditionnelle et les requêtes jusqu’à 100 fois plus vite. Selon Ellison, les opérations de reporting complexes seraient accélérées d’un facteur de 20.

Ces gains en mode « analytique » ne se font pas au détriment du transactionnel. Dans une base traditionnelle, a ainsi expliqué Ellison, l’OLTP est ralenti par les index : « quand on crée une table, on décide quels seront les champs indexés à des fins transactionnelles. On dispose ainsi en général de 1 à 3 index par table. Mais de plus en plus, on ajoute aussi des index pour accélérer les travaux analytiques complexes. » Ainsi pour chaque index destiné à optimiser les requêtes transactionnelles, 10 à 20 index sont créés pour accélérer les applications analytiques. Le problème, selon Ellison, est que la maintenance de ces index a un prix : chaque fois que l’on insère une ligne dans une table ou que l’on effectue une opération sur un enregistrement, il faut aussi maintenir les index à jour, ce qui nuit à la performance transactionnelle.

L’astuce avec l’option In-Memory est qu’il n'est plus nécessaire de maintenir les index « analytiques ». « On se débarrasse des index analytiques et on les remplace par le magasin de données en colonne In-Memory. On n’a plus besoin des index analytiques. De ce fait, l’insertion d’un enregistrement dans une table implique une mise à jour d'un ou deux index pour les transactions, il n’y a plus de pénalité pour l’analytique. Donc l’OLTP va plus vite », a expliqué Ellison.

Et le patron d’Oracle de se moquer implicitement Hana en pointant du doigt la simplicité d’activation de l’option In-Memory : « Pour allumer l’option In-Memory, il suffit de modifier le paramètre inmemory_size = xxx GB, de configurer les tables que l’on veut mettre en mémoire et de supprimer les index analytiques de ces tables », a expliqué Ellison. « En fait, c’est comme appuyer sur un interrupteur et toutes vos applications fonctionnent plus rapidement. Il n’y a pas de changement SQL, pas de migration de données, les applications fonctionnent sans modification », a-t-il ajouté. Et de préciser que l’option In-Memory fonctionne de façon transparente avec les nouvelles capacités multitenant d’Oracle DB, fonctionne avec Oracle RAC mais aussi avec les autres fonctions cœurs comme ASM (Automatic Storage Management) et surtout RMAN (Recovery Manager), l’outil de gestion des sauvegardes et des restaurations intégré à Oracle DB

Un nouveau grand serveur SPARC optimisé pour les applications in-memory

Larry Ellison présente le Sparc M6-32

Fidèle à sa stratégie de mise en œuvre de systèmes intégrés et optimisés couplant matériel et logiciel, Larry Ellison a complété le lancement de l’option In-Memory de la base Oracle par celui d’un nouveau serveur optimisé, le M6-32 Big Memory Machine. Ce serveur est en fait une évolution des serveurs M5 existants - il en reprend le chassis, la puce d'interconnexion NUMA et l'architecture... -, motorisée par les nouvelles puces SPARC M6, dévoilées lors de la conférence Hot Chips au mois d’août.

Chaque puce SPARC M6 dispose d’un nombre de cœurs doublé par rapport aux M5, ce qui permet l’assemblage d’un serveur NUMA massif capable d’offrir jusqu’à 384 cœurs et de traiter en parallèle jusqu’à 3 072 threads. Plus important encore pour les besoins In-Memory, le SPARC M6-32 est aussi capable de gérer jusqu’à 32 To de mémoire vive. Le tout est bien sûr couplé à des capacités massives de connectivité (32 ports 10 Gigabit en standard et la possibilité d’ajouter jusqu’à 64 cartes PCI-e 3.0). Selon Ellison, le M6-32 offre une bande passante interne de 3 To/s.

Le système peut servir de base à une configuration SuperCluster qui couple le M6-32 à un système de stockage Exadata via Infiniband. Une façon pour le moins intéressante d'associer la performance du M6-32 à un système de stockage optimisé pour les applications Oracle. Selon Ellison, il faut compter environ 3M$ pour un serveur M6-32 pleinement configuré (dont sans doute un bon tiers pour les seules barrettes mémoire). La firme n'a pas précisé le prix de l'option In-Memory pour Oracle 12c.