Andy Mendelsohn en dit plus sur le fonctionnement d'Oracle 12c in-memory

A l’occasion d’OpenWorld, LeMagIT a pu rencontrer Andrew Mendelsohn, le vice-président senior en charge des technologies de bases de données chez Oracle. Mendelsohn, pilote l’ensemble du développement des produits de abses de données de l’éditeur , dont Oracle Database, Oracle TimesTen, Oracle Berkeley DB, et Oracle NoSQL. Il travaille aussi sur les systèmes tels que Oracle Exadata Database Machine, l’appliance Oracle Database et l’Oracle Big Data Appliance. L’occasion de discuter un peu plu sen profondeur du fonctionnement de la nouvelle option in-memory de la base Oracle 12c, qui sauf retard imprévu, devrait être disponible au tout début du printemps 2014.

Andy Mendelsohn, vice-président en charge des technologies de bases de données, Oracle

LeMagIT : Quand vous avez une grosse base de données en mémoire, la question se pose de savoir comment vous assurez la persistance de ces données sur un support de stockage physique pour vous protéger contre toute défaillance matérielle, par exemple. Qu'en est-il dans le cas d'Oracle 12c lorsque l'on active l’option in-memory ?

Andrew Mendelsohn : La réponse en un mot est que rien n’a changé. Quand vous passez de 11g à 12c avec l’option in-memory, la façon dont nous gérons la persistance ne change pas. Il n’y a aucune modification. C’est la façon la plus simple de l’expliquer.

LeMagIT : Cela veut dire que la base de données en colonnes n’est qu’une représentation virtuelle et n’est jamais sauvegardée sur disque ?

Andrew Mendelsohn :C’est cela, elle ne va jamais sur disque. C’est un peu comme un index transitoire. Quand vous chargez votre base, on crée à la volée une représentation en colonne en mémoire. Cette structure évolue au fil de l’eau lorsque vous accédez aux données, les modifiez ou les interrogez. Elle ne vit qu’en mémoire, c’est pour cela que le mécanisme de persistance est inchangé. C’est un point très important.

LeMagIT : Si un changement est effectué sur un enregistrement d’une table comment se reflète-t-il dans le store en colonnes d’Oracle 12c in-memory ?

Andrew Mendelsohn :Dans 12c, avec l’option in-memory, nous gérons en parallèle deux formats de données, la représentation en lignes et la représentation en colonnes. On veille à ce que ces deux représentations soient en permanence synchronisées. Si vous faites des mises-à-jour, elles sont appliquées au « store » en lignes, car c’est le plus efficace pour cela. Ces modifications sont aussi stockées dans un "log" in-memory qui archive toutes les modifications au magasin de données en lignes. Périodiquement, ces modifications sont répercutées en batch sur le magasin en colonnes. 

Si quelqu’un réalise une requête sur la base de données, on combine les informations du store en colonnes et du log pour fournir une vision à jour et consistante de la base. On a toujours fait cela pour le store en lignes, en tout cas depuis 198,4 si ma mémoire ne me trahit pas. C’est ce que nous appelons assurer la consistance, mais cela fournit en fait un snapshot de la base.

Y a-t-il un plancher de mémoire en deçà duquel l’option in-memory n’est pas efficace ?

C’est une question intéressante. Je ne connais pas de limite formelle, mais cela dépend de la taille de votre base. Larry a réalisé sa démonstration sur scène avec un serveur bi-socket Intel qui avait 256 Go de mémoire, ce qui est une quantité raisonnable, mais rien d’impressionnant à notre époque. La base de données utilisée était plus petite que cela et tenait en mémoire.

Avec le store en colonne vous avez maintenant deux représentations des mêmes données. Est-ce que cela veut dire deux fois la quantité de mémoire pour une base d’une taille donnée ?

La quantité de mémoire, intuitivement devrait être double, mais on ne charge en mémoire que les données actives. Depuis déjà de nombreuses années, on met en cache les données actives de la base en lignes. Avec l’option in-memory, le DBA indique s’il veut une représentation en colonne pour certaines tables et il peut ensuite choisir entre plusieurs options, soit charger la table complète soit utiliser le partitionning et ne charger qu’un Shard. La quantité de mémoire consommée peut donc être très inférieure à la taille de la base de données. De plus la vision en colonne est fortement compressée. On estime la compression à un facteur de 5 pour 1, donc c’est très efficace et bien moins exigeant en mémoire que ce que pensent la plupart des utilisateurs.

Il convient de noter que la base Oracle a un concept de hiérarchie de stockage, avec la mémoire vive, la flash puis le disque. Sur nos appliances dédiées comme Exadata, il y a une grande quantité de Flash. D’une certaine façon le client a à faire un compromis entre le coût du stockage et la performance qu’il veut atteindre.

LeMagIT : Lorsque l’option in-memory est activée comment décidez-vous quelle représentation de la base vous allez interroger ?

Andrew Mendelsohn :L’optimiseur de requête d’Oracle décide quelle représentation utiliser pour traiter la requête. Si vous faites un update ou une insertion, les données sont écrites dans le magasin de données en lignes. Si vous faites un query analytique, il privilégie le magasin de données en colonnes.

LeMagIT : Un client Oracle me disait hier, j’ai ma base de données Oracle et à côté mon datawarehouse et je fais régulièrement des extractions de l’un vers l’autre pour pouvoir effectuer mes requêtes sur un jeu de données « à jour ». Et il s'interrogeait sur la possibilité, avec l'option in-memory,de ne plus utiliser qu'une base pour les deux usages.

Andrew Mendelsohn :En fait, les clients ont généralement deux approches : s’ils ont un datamart et que les données viennent d’une source unique, sans données externes, alors ce que vous décrivez est vrai. D’ailleurs des clients le font déjà avec 11g en créant des masses d’index pour accélérer les query. Certains clients refusent toutefois de créer ces index qui chargent le CPU et préfère externaliser les données de leur base de production vers un datamart dédié à l’analytique. Pour ces derniers clients, Un scénario de consolidation sous 12c est pour traiter à la fois l’OLTP et l’analytique est donc tout  fait envisageable avec l’option in-memory.

Toutefois, s’il est nécessaire d’intégrer des données de multiples sources, il faudra toujours un datawarehouse séparé.