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.

cf l’actu oracle sur developpez

Alors commençons par voir l’Hana-tomie de la bête …

Hana est une base de données de SAP ultra-performante, dopée aux Hana-bolisants comme :

• la gestion des données en mémoire (in-memory pour la traduction geek), qui comme tout le monde sait est beaucoup plus rapide que les disques durs (qui le sont un peu) ;
• le stockage en colonnes, avec un petit coup de compression pour optimiser tout ça ;
• le parallélisme jusqu’à la colonne (ça me donne froid dans le dos) ;
• le partitionnement pour découper tout ça au mieux (comme des Hana-nas) ;
• livrée en appliance (ie une machine livrée clé en main avec tous les logiciels déjà installés dessus), histoire d’avoir le hardware le plus adapté.

Par Hana-logie elle ressemble à Sybase IQ pour le stockage des données en colonnes et à Qlikview pour le côté in-memory. Mais halte à l’Hana-rchie architecturale, contrairement à ses concurrents Hana sait gérer du décisionnel (OLAP) et du transactionnel (OLTP) ; mettre de l’Hana dans un système opérationnel ne relève pas de l’Hana-chronisme et ça c’est fort !

Les résultats

Oubliez vos Hana-lgésiques, surtout si vous êtes sur BW (le Datawarehouse à la sauce SAP), Hana décoiffe !
Bénéficiant d’un moteur OLAP optimisé les performances sont sidérantes. C’est comme passer d’une télé 4/3 à 16/9, les données sont Hana-morphosées !
Paradoxalement la compression et le partitionnement ne plairont pas forcément aux pro-Hana qui pourront ingurgiter des milliards de lignes en quelques secondes.

Les critiques

S’il fallait lui lancer un Hana-thème on pourrait donner le prix de la licence, qui est un peu cher si c’est juste pour faire du datamart. On lui trouve aussi des aspects très homo-sapiens (plus du côté des R/3 que des erectus) comme la gestion de sessions/mandants, des RDS et des réplications sur les DD02, ce qui peut conférer des effets Hana-phrodisiaques à certains.

Et une petite Hana-phore pour la fin

Hana est une base Next-Gen, qui va vite, très vite.
Vite en restitution des données.
Vite en traitement des données.
Vite en Hana-lyse des données.
Vite en évolutions.
Vite pour remplacer les Bases de données classiques dans tous les environnements SAP (après Hana sur BW bientôt Hana sur R/3 !).
Bref, Hana est la base à suivre du moment.