jeudi 30 juin 2005

La fin des bases de données relationnelles


Laurent Bédé* , 01 Informatique (n° 1821), le 30/06/2005 à 00h00

Le langage SQL a joué un rôle de précurseur en sacrifiant vingt années d'alternatives sur l'autel du « on peut sûrement faire mieux, mais c'est un standard, et on s'en accommode » . Au début des années 80, l'apparition des systèmes de gestion de bases de données relationnelles (SGBDR) offre un cadre structuré et normalisé aux données. La nécessité de travailler avec un langage standard d'interaction avec les données et de fournir l'accès à ces informations à un utilisateur lambda donne naissance à SQL. On assiste alors à une extraordinaire arnaque intellectuelle, en retombant dans le piège de logiciels toujours trop compliqués pour un néophyte, ou trop limités pour un informaticien.

Aujourd'hui, après le télescopage du client-serveur et du web, les architectures à la mode nous font marcher sur la tête. Ainsi, les données stockées en mode relationnel sont extraites en SQL, de façon à alimenter un modèle objet, qui doit être à nouveau mis à plat pour l'ultime conversion à des fins de représentations tabulaires. Vu sous cet angle, la question se pose de savoir qui, de la base de données ou du serveur d'applications, doit rendre son tablier.

D'un aspect purement pragmatique, il faudrait détruire la brique du milieu, supprimant la double distorsion (relationnel/objet et objet/représentation tabulaire), et par là même quelques décennies d'avancées technologiques. N'en déplaise aux conservateurs, je préfère une autre option.

Les serveurs d'applications prennent le relais

Car, en regardant de plus près, les SGBDR représentent « le » point faible des architectures à plusieurs niveaux. Risques d'indisponibilité, problèmes de performances, évolutivité trop verticale... Leur mode d'interaction n'est plus du tout en phase avec les standards de développement objet et XML. En outre, les futurs ingénieurs ne sont plus formés au SQL, et encore moins aux formes normales. Mais alors, si la base de données disparaît, qui prend le relais ? Les serveurs d'applications bien sûr. Un exemple : même si dans le monde Java, les premières spécifications des EJB Entity ont échoué pour donner naissance dans la foulée à JDO, d'un côté, et à Hibernate, de l'autre, elles proposent une façon ­ plutôt incompatible ­ de résoudre la différence d'impédance objet/scalaire. Peu importe, la bataille acharnée que se livrent les partisans des deux camps, tous ceux qui ont expérimenté ce mapping objet/relationnel (ORM), dressent un même constat : la différence se fait autour de la gestion du cache.

Un langage d'interrogation objet pour remplacer SQL

Une unification des ORM est attendue en fin 2005. Le cache, lui, restera encore longtemps loin de toute normalisation. Qu'il s'agisse de celui de niveau 1, propre à chaque session (ou transaction) qui assure qu'un objet n'est instancié qu'une seule fois ; ou de celui de niveau 2, qui propose des services de réplication transactionnelle interserveurs, de tolérance aux pannes, de gestion de conflit sur mise à jour concurrente, et, enfin, de tolérance à l'absence de base de données. Ce cache en écriture, réparti sur toutes les instances d'une grappe de serveurs d'applications, supprime de facto le goulet d'étranglement inhérent aux moteurs de persistance classiques. Un langage d'interrogation orienté objet remplace alors SQL ; la distorsion objet/relationnel est éliminée, et avec elle le mapping. Cerise sur le gâteau, on administre les composants exécutables et leurs données depuis une console unifiée. Les conditions optimales pour l'arrivée d'un mode de persistance asynchrone, distribué et à évolutivité horizontale et linéaire, se trouvent donc réunies. Une telle technologie peut donc ­ en théorie ­ prétendre se substituer au SGBDR et le reléguer au rang des bandes magnétiques d'archivage.

Bien entendu, tout cela n'en est encore qu'au stade préhistorique. Les fournisseurs se défendent en faisant la promotion du Datagrid ; d'autres mettent l'accent sur les développements Javaspace, JCache ou propriétaires.

* directeur technique du projet AceTP chez BNP Paribas Securities Services

2 commentaires:

Bernard Notarianni a dit…

Cher Laurent,

Dans ce que vous décrivez, la préhistoire a déjà écrite il y a 20 ans. Les langages objet sans SGBDR existent depuis longtemps, et ils marchent déjà.

http://www.gemstone.com/products/smalltalk/

Le problème n'est pas uniquement SQL, mais Java/J2EE+SQL. Il est en effet temps de revenir à ce qui marchait déjà il y a 20 ans. Tout ceci n'a été qu'une parenthèse initiée par le langage C dans les années 70, qui a surfé sur le succès d'Unix face aux couteux Mainframe et à l'instable MSDOS. Nous avons toujours le choix de revenir à des solutions simples et qui marchent.

Unknown a dit…

Cher bernard,

tu sais tout le bien que je pense de smalltalk, mais :

il y a bien un sgbd dans smalltalk, les états des objets sont sauvegardés quelque part (dans l'image) et accessible au lancement de la vm.

il n'est pas relationnel, il est vrai. par contre je te met au défi d'accéder à ces objets depuis un autre language, une autre interface ...

sql a au moins cet interet : il existe des drivers pour beaucoup de langages, et sinon il y a toujours moyen de s'interfacer à un driver propriétaire

les données relationnelles ont d'autres qualités : leur intégrité peut être garantie. On peut les contraindre, les valider ...

comment reproduit-on les contraintes en objets ?
comment reproduit-on la notion de transaction en objet ?
et les caches ?