Chiron (2/11) : fin des SGBDR, maintenant !

[Laurent Caillette]

2018 c'est le début de la fin des SGBDR. C'est comme ça. Oracle et Sybase ne mettront pas la clé sous la porte tout de suite, il y aura encore des applications en production pour utiliser ces machins, mais une sorte de tressaillement dans l'air nous fera bien sentir que oui le SGBDR ça avait son charme, il fut un temps. C'est une prophétie autoréalisatrice, si elle échoue ça sera la faute de ceux qui ne lisent pas Techos. Tout ce qui va être dit dans ce billet pourrait avoir été dit en 2017 ou en 2016 ou avant ; mais une fois qu'on l'a dit c'est difficile d'oublier vers quelles profondeurs d'inanité technologique nous entraînent ces produits, donc j'affirme sans peur que la fin des SGBDR commence //immédiatement//, à la seconde même où tu lis cette phrase. 

Il faut faire un petit peu d'histoire pour bien comprendre d'où vient leur actuelle prééminence. Vers le dernier quart du siècle dernier, les applications d'informatique de gestion, généralement développées en COBOL, accédaient à des fichiers avec des enregistrements de taille fixe, et la moindre génération de rapport passait par un chantier de deux mois. Quand j'étais petit mon père m'emmenait à son travail et j'ai vu des gens pousser des chariots chargés de disques durs de 100 Mo qui se présentaient comme des cloches de plastique abritant des plateaux de métal superposés de 40 cm de diamètre. Ils planifiaient sur un cahier les copies de fichiers 15 jours à l'avance. Tout ça pour dire que l'agilité n'était pas au rendez-vous et ce n'était pas du goût des chefs de quelque chose qui voulaient leur rapport tout de suite et qui haissaient ces informaticiens qui au fond avaient plus de pouvoir qu'eux. Je la fais courte, le SGBDR s'est imposé dès que la densité d'information des processeurs et des mémoires de masse l'ont permis. Et la magie se fit : le développement qui prenait 2 mois s'est vu remplacé par un `ALTER TABLE` ou un `SELECT * FROM EMP`. Ce choc fut d'une telle ampleur qu'il suscita un étonnant mouvement religieux d'entreprise, basé sur la croyance que le monde pouvait se représenter sous forme de modèle relationnel. C'est comme la guerre : certaines transitions historiques laissent dans la mémoire collective des traces indélébiles, et il devient très difficile de questionner les réflexes acquis à ces moments-là ; d'autant plus que ceux qui n'ont pas vécu cette transition reproduisent ces mêmes réflexes parce qu'ils sont devenus des gestes sociaux structurants. 

Je sens venir l'objection habituelle : "Oui mais les SGBDR sont une solution technologiquement mature." Ha ha ! En informatique une solution n'a que deux états : immature et obsolète. "Mature" c'est le terme codé pour dire "Obsolète, mais je fais trop de pognon pour oser le dire à mes clients." Ceux qui travaillent chez un éditeur de SGBDR peuvent arrêter la lecture avant que ça devienne trop dur pour eux.

Non, sérieusement, comment expliquer à quelqu'un venu d'une autre planète que l'informatique de gestion s'appuie massivement sur les SGBDR, alors que //par définition// le modèle relationnel fait tout pour omettre la notion de traitement, et ne conserve que l'état final des données ?

Je la refais au ralenti, parce que c'est important.

Le modèle relationnel des données, c'est facile et gratifiant à produire, donc allons-y réinventons le monde avec des rectangles et des traits. Une fois qu'on a ce truc beau et apparemment complet, il n'y a pas moyen de greffer une représentation des traitements dessus. Autrement dit le relationnel incite à négliger la notion de traitement au niveau de l'analyse. Ou alors il faut inventer une autre représentation, et se taper la mise en cohérence à la main.

L'état final c'est sympa, mais ça ne dit rien sur comment on a pu obtenir de telles données. La plupart des applications nécessitent une piste d'audit, et on a souvent besoin de recréer le flux de données en entrée, que ce soit pour investiguer des cas d'erreur ou effectuer des tests de performance. La conservation du seul état final c'est une survivance du temps où la gamelle de 100 Mo valait sa centaine de milliers de (nouveaux) francs. 

Les deux critiques ci-avant s'appliquent à la plupart des bases de données, y compris celles qui ne sont pas relationnelles. Mais en général ceux qui optent pour une approche non-relationnelle sont déjà dans une configuration mentale plus adaptée au questionnement des besoins et des solutions.

Il y a un cas où les SGBDR carburent vraiment, c'est le décisionnel avec un modèle en étoile. Le modèle en étoile utilise une table centrale appelée "table de faits" qui met en relation des tables périphériques appelées "tables de dimensions". Il n'y a jamais de suppression ou de mise à jour, que des ajouts. L'analyse consiste à mettre en relation le contenu des tables de dimensions en passant par la table de faits. Cette approche met à profit les capacités de jointure sur des volumes énormes. Ceci dit le modèle en étoile est un piratage complet de la forme normale, et sous-entend la non-utilisation de beaucoup des fonctionnalités classiques d'un SGBDR. Comme il n'y a que des insertions, on résoud les deux principaux problèmes : il n'y a pas à modéliser de modifications, et l'état final n'est jamais bâti sur une perte de données. Avouons qu'il est tentant de conclure que c'est dans le contre-emploi que le SGDBR cesse d'être un problème.

Mais pour ceux qui veulent écrire une application d'informatique de gestion le problème reste toujours le même : le SGBDR protège son propre monde et le code applicatif n'est pas le bienvenu. Les tentatives d'inclure de la logique applicative dans le SGBDR n'ont fait qu'ajouter à la confusion avec les procédures stockés ; les tentatives de rapprocher le code applicatif du SGBDR avec la projection objet-relationnel ont donné des modèles de programmation fort peu convaincants. Ce n'est pas un hasard ; d'un côté on a un modèle de graphe avec un système de requêtage qui peut ramener tout et n'importe quoi lors d'opérations bloquantes. De l'autre on a du code qui essaye de s'appuyer sur des structures bien définies, et qui ne doit pas effectuer d'opérations bloquantes si on veut maximiser les performances. 

Le plus pénalisant c'est bien sûr l'inadéquation entre les langages impératifs de haut niveau (Java, `C#`, `C++`...) et la structure relationnelle qui impose un graphe simpliste. En gros, toute tentative de projection objet-relationnel implique un grand écart mental : on a un langage de haut niveau mais pas le droit de s'en servir efficacement, c'est à dire qu'on passe son temps à se contorsionner entre les idiomes nécessaires pour complaire au SGBDR. 

Une autre bizarrerie des SGBDR c'est de promouvoir un modèle requête-réponse pas du tout approprié à un fonctionnement où plusieurs clients (qui peuvent être des serveurs applicatifs) souhaitent être notifiés des changements opérés sur un ensemble de données. Bien sûr on peut bricoler des trucs horribles avec les déclencheurs ("triggers") mais on perd le contexte de la modification, par exemple la session de l'utilisateur qui l'a initiée. Dans ce cas la solution c'est bien sûr d'ajouter une couche horizontale d'envoi de messages, qui n'a juste plus rien à voir avec la logique d'un SGBDR. On pourra toujours trouver quelques bricolages pour limiter les dégâts mais il est clair que les SGBDR ne sont pas faits pour fonctionner dans un environnement distribué.

Quand je relis une discussion comme celle initiée par Julien "Cherche feedback sur un mini-ORM SQL en Java"

https://groups.google.com/d/topic/techos/FCfY6AjTi0c/discussion

je me dis que le problème nous colle aux doigts depuis plus de 30 ans et il n'y a pas de bonne solution en vue. Pour donner un aperçu des avancées dans d'autres domaines, on a réglé leur compte à des trucs jadis terrifiants comme la gestion de la mémoire et les développements multiplateformes.

Pour l'instant nous n'avons passé en revue que des maux intrinsèques aux SGBDR. Quand on regarde les produits du marché on constate que les solutions sur étagères sont entachées de défauts que les éditeurs n'ont aucune intention de corriger. Que ce soient la complexité d'installation de produits "poids lourd" comme Oracle ou Sybase, ou les subtilités de l'import-export de base, on sent que les éditeurs ont raté le coche des DevOps et de l'usine logicielle. Le SGBDR d'Oracle comme bibliothèque Java disponible sur Maven Central, avec une option pour fonctionner uniquement en mémoire vive, ça serait chouette, non ? Eh bien ça n'arrivera pas parce que le modèle économique d'Oracle nécessite un produit excessivement compliqué. 

C'est terrible de constater qu'on peut endurer tant de souffrances juste pour prolonger une vision de l'informatique bâtie du temps où fallait il pousser des deux mains pour faire avancer le chariot contenant `2 Go` de données sur des disques durs. `2 Go` c'est la taille maximale d'une ``String`` en Java.

Tiens juste comme ça, combien de gens manipulent des bases de données non-historiques, donc sujettes à des modifications fréquentes, et qui pèsent plus de `512 Go` ? Sans compter les champs binaires. `512 Go` c'est ce qu'on peut mettre comme mémoire vive sur un serveur OVH loué au mois pour le même prix qu'une journée de consultant. C'est à peu près la taille maximale du tas d'une JVM. Autrement dit, si tout tient en mémoire vive quel besoin de traîner un logiciel inventé pour minimiser les accès à la mémoire de masse ?

2018, quoi ! il n'est jamais trop tard pour arrêter de se faire du mal.

[Laurent BEDE]

Amusant, je disais la même chose en 2005 !

http://privatelab.blogspot.fr/2005/06/la-fin-des-bases-de-donnes.html

--
Vous recevez ce message, car vous êtes abonné au groupe Google Groupes "techos".
Pour vous désabonner de ce groupe et ne plus recevoir d'e-mails le concernant, envoyez un e-mail à l'adresse techos+unsubscribe@googlegroups.com.
Pour envoyer un message à ce groupe, envoyez un e-mail à l'adresse tec...@googlegroups.com.
Visitez ce groupe à l'adresse https://groups.google.com/group/techos.
Pour obtenir davantage d'options, consultez la page https://groups.google.com/d/optout.

[Laurent Caillette]

Salut Laurent,

C'est sûr, l'envie de régler leur compte aux SGBDR ne date pas d'hier. Dans ton billet tu expliques que le SGBDR va perdre sa prépondérance au profit du cache distribué. 

Avec Memcache intégré en standard à Google AppEngine on peut dire que oui, ce modèle d'architecture a prouvé sa validité. Par contre tu ne dis rien sur la façon de persister les données. Bon il y a une console d'administration et il se passe des choses magiques, mais concrètement, comment les données sont-elles aplaties, répliquées, comment se font les montées de version ? Comment faire tout ça sans se jeter dans les bras du SGBDR qui le propose déjà plus ou moins ? 

Le simple fait de parler de graphe d'objets dans un cache ça oriente vers une vision entité-relation, donc relativement compatible avec un SGBDR si le discours commercial parvient à minimiser les problèmes liés à la projection objet-relationnel. Ça n'a pas fait un pli, les vendeurs de SGBDR se sont engouffrés dans la brèche en proposant des outils par-dessus ce qu'ils maîtrisaient déjà. La preuve : le rachat par Oracle de Coherence, puis de Sun. 15 ans après ton article s'avère assez exact. À part le titre, parce que justement Oracle a senti le vent tourner.

Si tu veux exterminer les SGBDR il faut que l'approche entité-relation ne soit plus quelque chose qui conditionne toute l'architecture. Ça implique de se passer d'un cache distribué. Ce n'est pas tout à fait ce que tu proposais.

(Hé, c'est courageux de ressortir des trucs écrits voilà plus de 10 ans !)

[Henri Tremblay]

Le problème c'est l'état actual. En DDD, tu traites des évènements. Mais il faut quand même avoir un vu présente qui est l'agglomération de tous les évènements. Ta base de données te donne ça.

Et en effet, rien n'empêche d'avoir tout ton modèle en mémoire. Mais c'est souvent plus pratique de l'avoir en objets java. Les moteurs de CEP font pas mal ça. Toutefois, ça implique la redondance qui va avec.

Les bases de données en mémoire il y en a pas mal. Et compatible Devops aussi. Il n'y a que Oracle qui n'est pas gentil (et Sybase, mais c'est mort). Mais tu peux tourner du MySQL embedded. Et H2. Plus tout le tas de NoSQL... mais ceux-là sont dangereux car douteusement transactionnel souvent. Mieux vaut ne pas mettre de sous dedans.

[Laurent Caillette]

Salut Henri,

C'est quoi le DDD et le CEP ?

[Henri Tremblay]

DDD = Domain Driven Design (voir le livre d'Éric Evans). Qui est un amas de trop de choses mais en autre le fait d'enregistrer des évènements et non juste de changer de CRUD. Comme ça tu sais ce qui est arrivé. En lecture, tu as une vue finale toutefois.

CEP = Complex event processing. Un machin qui garde des variables en mémoire et reçoit des évènements. Le machin a un jeu de règles effectuant des changements selon l'évènement.

[Laurent Caillette]

OK merci. Ma réponse arrive dans les épisodes suivants.