Oracle dispense sa leçon sur les bases de données In-Memory

Après l'annonce de l'option In-Memory de sa base de données en septembre et son « lancement officiel » par son CEO Larry Ellison la semaine dernière, Oracle a détaillé les fonctionnalités de sa technologie à Francfort mardi, puis à Paris hier après-midi. L'ordre de la tournée n'est évidemment par un hasard. Cette opération auprès de ses clients et prospects vise à clarifier encore le positionnement du leader mondial de la base de données, qui arrive après IBM ou Microsoft, et bien après SAP sur le marché porteur associant analytique en temps réel.

Cependant, si la solution In-Memory Hana de SAP résonne autant sur le marché SAP, ce n'est pas uniquement pour ses performances rendues possibles par une exécution en mémoire, évitant les ralentissements dus aux entrées/sorties et aux accès disques. Le succès s'explique surtout par la réponse à une demande pressante des entreprises de disposer d'analyses en temps réel sur les données de production. Bien que les datawarehouses traditionnels puissent conserver de l'intérêt pour les analyses a posteriori. Et lorsque le leader mondial de l'ERP propose sa propre solution de bases de données, le danger devient réel, même pour le numéro deux de ce marché (voir notre article).

Oracle dispense sa leçon en bases de données

« Pour accélérer les traitements analytiques, Oracle a déployé depuis plusieurs années le stockage en colonnes,» explique Andrew Mendelsohn, directeur Oracle Database Server Technologies. « Si ce procédé s'avère efficace pour les applications analytiques, le stockage en ligne reste toutefois beaucoup plus performant pour le transactionnel de type ERP. Certaines applications font essentiellement de l'analytique, mais dans la quasi-totalité des cas, les applications d'entreprise nécessitent à la fois le mode colonne et le mode ligne. C'est pourquoi, contrairement à SAP dont la solution In-Memory stocke tout en mode colonne, Oracle a opté pour une solution combinant les deux modes.»
« La technologie TimesTen datant de la fin des années 90 fonctionne en mode ligne. Elle a pour objectif d'accélérer le production des requêtes sur une base de données intégrée à un logiciel pour les faire passer de l'échelle des secondes à celle des microsecondes. Elle n'a pas vocation à fonctionner en dehors de ce cadre,» rappelle Andrew Mendelsohn.

Et Oracle de souligner les 850 tests en situation réelle lancés depuis septembre, et la centaine d'entreprises ayant contribué à son programme de beta-test In-Memory depuis mars dernier. Bien entendu, les performances sont fortement améliorées jusqu'à plusieurs centaines de fois plus rapides (de jours en secondes) selon les applications et les traitements, et les données transactionnelles sont également impactées, avec des améliorations dépendant évidemment de l'existant.

La simplicité sans rupture du In-Memory à la volée

Pour parvenir à cette cohabitation, l'utilisateur indique simplement les tables ou partitions de table (toute la base de données s'il le souhaite) pour lesquelles il souhaite disposer des données In-Memory. « Nous n'obligeons pas l'entreprise à tout monter en mémoire. Inutile de monter plusieurs téraoctets en DRAM, pour un coût plus que conséquent ! » insiste Andrew Mendelsohn.

Alors, le moteur d'Oracle 12c effectue les mises à jour à la fois dans la base et dans la partie In-Memory de façon synchronisée. Lorsqu'une requête est envoyée, le Query Optimiser va puiser l'information dans la partie In-Memory ou dans le stockage en ligne selon la nature et la complexité de la requête. Bien entendu, l'entreprise peut alors supprimer de la base de données les index analytiques devenus inutiles, ce qui accélère d'autant les traitements de sa base de données, inchangée pour tout le reste.

Les migrations et les ruptures technologiques se transformant souvent en cauchemar pour les DSI, Oracle insiste sur la simplicité de déploiement de son option In-Memory : indiquer de la capacité mémoire à utiliser, configurer les tables ou partitions de table à installer (aussi) en mémoire une ligne de type SQL, et supprimer les index analytiques. « Contrairement à SAP, Oracle In-Memory ne nécessite pas de migrer intégralement la base de données vers une autre technologie, ni de réécrire une seule ligne de code dans les applications existantes », martèle Andrew Mendelsohn. En outre, les politiques d'accès et de contrôle des utilisateurs de la base restent identiques et cohérentes.

Autre avantage de l'aspect très peu intrusif du In-Memory dans les bases de données existantes (à partir de la version 12c uniquement) permet à l'entreprise de continuer à profiter des expertises en place, et ne nécessite donc un minimum de formation. Certains diront : « aucune formation ». Toutefois, quel DBA utiliserait une technologie sans disposer d'un minimum de bases théoriques ?

Sur toutes les plates-formes, et un peu plus

Pique supplémentaire envers le leader de l'ERP par l'évangéliste technologique d'Oracle: « contrairement à SAP Hana, notre solution fonctionne sur toutes les plates-formes matérielles ou virtuelles et dans le cloud, sans nécessiter une certification spécifique avec du code adapté.»

Par ailleurs, Oracle met l'accent sur une autre différence : son travail depuis plusieurs années avec Intel et sur ses propres processeurs. « Notre option In-Memory bénéficie pleinement des instructions SIMD (Single Instruction for Multiple Data values) des processeurs modernes. Grâce aux vecteurs d'instruction SIMD Oracle In-Memory peut traiter plusieurs valeurs de colonnes en un unique cycle, d'horloge CPU,» rapporte Andrew Mendelsohn.

Enfin, parce que toutes données ne sont pas forcément en mémoire, une architecture multi-tiers reste possible. L'entreprise peut ainsi répartir ses données : en mémoire pour celles nécessitant de très hautes performances, sur disque flash pour celles exigeant de la performance et le disque dur pour les autres. Une répartition qui devrait séduire les DSI à la recherche d'un juste équilibre entre coûts et performances.

Peut-on réellement se fier à la mémoire ?

La compatibilité avec la technologie existante permet à Oracle de faire bénéficier sa technologie In-Memory des atouts de la haute disponibilité et de sécurité existantes et éprouvées comme son architecture MAA (Maximum Availability Architecture).

Le fait que le format de stockage reste inchangé (les ordres "redo" ou "undo" restent valables) autorise en effet l'utilisation transparente des fonctions et options Oracle pour la sauvegarde, la restauration, la réplication, la supervision, etc. Monter des données en mémoire pose cependant la question de la gestion de la persistance de l'information sur un support volatile. Oracle a donc déployé un mécanisme de tolérance aux pannes In-Memory. Classiquement, lorsqu'un serveur tombe, un autre noud prend le relais. Et la reconstruction du noud tombé impacte fortement les performances globales.

La fonction Oracle In-Memory Fault-Tolerance permet optionnellement de dupliquer les données dans la mémoire de deux nouds d'un cluster. Disponible pour ses serveurs Engineered Systems, cette option pourrait aussi s'avérer utile sur d'autres plates-formes. « Plusieurs années en tant que spécialiste des bases de données ont été nécessaires pour parvenir à ce niveau de sécurisation et de stabilité sur ce type de solution,» lâche sournoisement Andrew Mendelsohn.

Le prix de l'option In-Memory ne sera rendu public qu'en juillet, mais Oracle indique que le mode de tarification sera conforme aux pratiques traditionnelles de la base de données Oracle.