Enfin, Oracle sort une option « InMemory » pour fournir une base vectorielle digne de ce nom à sa base transactionnelle classique.
Comment ça marche ?
On garde le stockage en ligne classique et on apporte une couche supplémentaire de stockage en colonnes et en mémoire. En fonction de la requête SQL qui est exécutée, le moteur Oracle va chercher les données sur le stockage classique en lignes ou en mémoire dans un stockage en colonnes.
Ce stockage en mémoire et colonnes rappelle celui de solutions déjà existantes, comme Qlikview, Microsoft PowerPivot, SAP HANA et bien d’autres.
Comme la mémoire est limitée seules certaines tables seront montées en mémoire. C’est au DBA ou à l’architecte/concepteur BI de sélectionner les tables candidates. A priori on peut aussi ne choisir que certaines partitions.
Le résultat
Les requêtes sont bien plus rapides sur des volumétries importantes, ce qui n’est pas étonnant quand on compare avec les solutions similaires.
Mais les requêtes transactionnelles gagnent aussi en rapidité ! En effet certains index ne sont plus d’utilité et sont donc supprimés (a priori les index bitmap).
Les contraintes
- C’est une option, ce n’est donc pas gratuit. Mais comme pour le partitionnement c’est une option obligatoire pour une base décisionnelle.
- Il faut une base en 12c, donc il est probable qu’il faudra monter de version les bases existantes …
Le reste de la famille
Exalytics est une appliance qui jouait le rôle de cette couche inmemory pour analyser les données rapidement. Le packaging est différent, mais ça fait doublon.
Cela signe aussi la fin des cubes Oracle (Essbase ou OLAP) si le temps de réponse est satisfaisant avec le inmemory.
Pour les autres (TimesTen, Big Data) le terrain de jeu n’est pas le même.
Et le reste du monde
SAP HANA est clairement visée. Il est vrai que SAP vend sa base comme LA base pour l’analytique et le transactionnel, et marchait sur les plate-bandes d’Oracle.
Ce dernier a vite mis en ligne un comparatif entre les deux bases de données, à son avantage évidemment.
SAP a vite rétorqué en commentant directement dans le document incriminé.
Loin de cette querelle fratricide on retiendra juste que :
- Oracle 12c inmemory n’est pas une base gérée totalement en mémoire comme HANA, c’est plus ce qu’on appellera « un cache » pour l’analytique.
- HANA n’est disponible que sur appliance ou cloud, ce qui est normal car il faut un matériel de compétition pour la faire tourner. Ce n’est pas le cas d’Oracle.
Les deux bases sont bien différentes, le choix va être difficile …
Oui mais …
L’idée est intéressante sur le papier. On bénéficie des deux modes de stockage, les applications transactionnelles et analytiques cohabitent sans problème. On peut récupérer instantanément tout un enregistrement en ligne pour une application transactionnelle, et on pourra calculer des agrégats complexes sur des volumétries importantes en un clin d’oeil.
L’application idéale semble le reporting opérationnel en temps réel, soit des états qui attaquent directement une base transactionnelle de production avec un temps de réponse instantané.
Pourtant quand on connait les bases en colonnes existantes, on sait qu’il existe un goulot d’étranglement quand on ajoute ou modifie une seule ligne. Or c’est ce qui se passe tout le temps sur une base transactionnelle classique. Alors comment va réagir la base Oracle inmemory ? Y a-t-il un temps de latence pour prendre en compte ces ajouts/modifications de ligne ? A-t-on vraiment du temps réel ?
Néanmoins il faut avouer que c’est une excellente pour le monde BI, les bases Oracle étant bien implantées dans notre univers.