OpenWorld 2012 : des détails sur Oracle 12c et ses bases de données empilables

Contrairement aux bases de données Open Source MySQL, dont on peut suivre les travaux en toute transparence, le travail que réalise Oracle sur sa base de données se fait en grande partie à huis clos. Si bien que l'on sait peu de choses sur la manière dont fonctionneront ces bases de données empilables et il faudra attendre environ un an avant la sortie de la nouvelle version. Cependant, depuis l'intervention de Larry Ellison, le CEO d'Oracle, dimanche dernier, certains éléments ont commencé à filtrer sur le sujet. Déjà, au cours d'une session de la conférence OpenWorld 2012, deux des principaux architectes d'Oracle 12c, le chef de produit Bryn Llewellyn et l'architecte Kumar Rajamani, ont expliqué en quoi Oracle 12c différerait de la base de données actuelle 11g. Le vice-président de la société, Tom Kyte, qui alimente le blog technique bien connu Ask Tom Oracle, a également dit en quoi les bases de données empilables faciliteraient le travail des utilisateurs.

Essentiellement, dans le nouveau design, la base de données actuelle a été séparée en deux entités distinctes. Bryn Llewellyn a qualifié l'opération de «séparation architecturale ». Une premier partie, souvent désignée comme base de données Root ou base de données conteneur, abritera toutes les fonctionnalités et les métadonnées nécessaires pour faire tourner la base de données elle-même. L'autre portion sera dédiée à l'utilisateur et sera indépendante de la base de données conteneur. « Nous avons isolé les métadonnées d'Oracle des métadonnées du locataire », a expliqué le chef de produit d'Oracle. « La partie Root contient les métadonnées Oracle, et la base de données empilable contient les métadonnées client », a-t-il ajouté.

Une séparation claire des opérations effectuées par la base de données elle-même et celles qui concernent le contenu utilisateur marque une évolution majeure par rapport à l'architecture des bases de données traditionnelles. « Oracle 11g, et tous ses prédécesseurs, ne savent exécuter qu'une seule base de données à la fois », a expliqué Tom Kyte. Si une entreprise veut exécuter plusieurs bases de données sur un serveur unique, elle doit doit faire tourner plusieurs instances Oracle 11g, une pour chaque base de données. Comme son nom l'indique, les bases de données empilables vont permettre de faire tourner des bases de données multitenant sur une seule copie de 12c. « En fait, Oracle 12c pourra faire tourner jusqu'à 250 bases de données utilisateurs », a déclaré Bryn Llewellyn, ajoutant que 250 est un nombre arbitraire choisi par Oracle, mais que l'architecture pouvait probablement en supporter davantage. « La nouvelle base de données est compatible avec les bases de données antérieures d'Oracle», a encore précisé le chef de produit. Ce changement dans l'architecture apporte un certain nombre d'avantages, sur lesquels l'éditeur a communiqué durant sa semaine de conférences, comme une meilleure performance, une sécurité renforcée et des mises à jour plus faciles.

Un des slides présentés lors de l'annonce d'Oracle 12c

Aujourd'hui, la plupart des entreprises font soit tourner de multiples bases de données sur un serveur unique, soit elles essaient de construire une énorme base de données qui prend en charge de multiples applications. Selon le message martelé par Oracle pendant la semaine, « les deux approches sont inefficaces ». Lors de son discours d'ouverture de mardi dernier, Larry Ellison a déclaré qu'il « était très critique quant au multitenant au niveau de la couche d'applications ». Selon lui, les outils de sécurité ne peuvent pas fonctionner correctement dans cette architecture. « L'isolement des données devait se faire au niveau de l'infrastructure - des machines virtuelles distinctes - ou au niveau de la couche abritant la base de données », a-t-il dit. « Mais, entre ces deux options, c'est la couche de base de données qui est la plus efficace », a fait valoir le PDG d'Oracle.

« La base de données empilable est intrinsèquement plus efficace pour un certain nombre de raisons », a expliqué plus tard Kumar Rajamani. Aujourd'hui, un serveur exécutant 100 bases de données doit basculer rapidement entre toutes ces bases de données, ce qui est très lourd. « Une centaine de binaires sont orientées vers une centaine de commutateurs de tâche », a-t-il ajouté. Avec une base de données unique, on élimine ces va-et-vient multiples. En outre, chaque base de données effectue un grand nombre d'opérations en arrière-plan qui doivent fonctionner en continu, et le fait de réduire et d'unifier l'ensemble de ces processus permet d'économiser des ressources. De plus, comme on a besoin d'une seule copie du logiciel de base de données pour gérer les bases de données multi-utilisateurs, on peut aussi réduire la quantité d'espace disque nécessaire, puisque on ne doit plus loger les multiples copies du logiciel de la base de données hôte. (Oracle n'a pas précisé quelle incidence cette nouvelle architecture aurait sur les coûts de licence.)

Dans le passé, les entreprises qui ont essayé de consolider leurs données sur une seule base de données ont rencontré un certain nombre de difficultés. D'une part, elles se heurtent à des problèmes d'espace de nommage dans le cas où les noms des colonnes d'une table de base de données utilisateur sont identiques à ceux d'une autre base, et il faut les accorder ensuite sur une base individuelle. En outre, il est difficile de contrôler efficacement l'accès aux bases de données multi-usages. Différents utilisateurs impliquent des tables différentes, mais la définition des droits d'accès pour chaque utilisateur au niveau de la base de données peut être long et source d'erreurs (voir les travaux de Jim Starkey avec NuoDB à ce sujet).

Cependant, l'architecture de base de données empilable pourrait résoudre ces problèmes. Dans les bases de données d'utilisateurs distincts, les espaces de nommage seront tout à fait indépendants les uns des autres, et les doublons ne poseront pas de problème. Elle résout aussi la question des droits d'accès. Oracle promet que la séparation entre deux bases de données empilables sera aussi étanche que la séparation entre deux bases de données actuelles, complètement indépendantes.