Pourquoi les bases de données et leur complexité sont désormais inutiles

Les problèmes des bases de données et pourquoi leur complexité est inutile

• Les bases de données constituent un état global mutable, ce qui complique le code et le rend plus difficile à comprendre.
• Les modèles de données sont limités et ne peuvent pas couvrir tous les cas d’usage, ce qui impose d’utiliser plusieurs bases de données.
• Le dilemme normalisation vs dénormalisation crée une tension entre cohérence des données et performances.
• Des schémas limités introduisent de la complexité pour faire entrer l’expression du domaine dans le moule de la base de données.
• Des déploiements complexes augmentent les coûts et la complexité à cause de la combinaison et de l’intégration de nombreux outils.

Un modèle cohérent pour construire des backends d’application

• La fonction de base d’un backend est de recevoir de nouvelles données et de répondre à des questions sur ces données.
• La conception idéale d’un backend doit se rapprocher autant que possible de cet idéal tout en respectant les contraintes réelles.

Rama

• Rama est une plateforme de développement backend qui réimplémente Mastodon pour fournir un service à l’échelle de Twitter.
• Rama implémente tous les éléments du backend — données, index, ETL, requêtes, etc. — de manière unifiée.
• Rama simplifie les déploiements complexes et intègre la supervision, réduisant fortement les coûts de développement et de maintenance.

L’avis de GN⁺

• Le problème d’état global mutable des bases de données augmente la complexité du code et le risque d’erreurs, un problème auquel les développeurs sont souvent confrontés.
• Rama propose une nouvelle approche qui dépasse les limites des bases de données traditionnelles et réduit la complexité du développement backend.
• Cet article offre des informations intéressantes et utiles aux développeurs qui cherchent à réduire la complexité des bases de données et des systèmes backend.

[GN⁺]

Avis Hacker News

• Il faut utiliser un sous-système qui représente la source de vérité, et un autre sous-système qui implémente plusieurs stockages d’index dérivés de cette source. C’est la combinaison de l’event sourcing et des vues matérialisées.

  • Event sourcing et vues matérialisées : la solution consiste à gérer séparément le système qui représente la source de vérité et les stockages d’index qui en dérivent.

• Nous séparons le modèle de lecture et le modèle d’écriture : le modèle d’écriture (la « source de vérité ») est composé d’un modèle de domaine relationnel traditionnel, et presque toutes les commandes génèrent des événements publiés dans une file partagée d’événements de domaine. Le modèle de lecture est constitué de workers qui consomment ces événements et construisent des vues.

  • Séparation des modèles lecture/écriture : le modèle d’écriture repose sur un modèle de domaine relationnel, et les commandes génèrent des événements publiés dans une file d’événements de domaine. Le modèle de lecture consomme ces événements pour construire des vues.

• La matérialisation lors des changements de données peut être avantageuse quand le produit doit effectuer une seule tâche très rapidement. Mais des problèmes apparaissent lorsqu’on veut ajouter de nouvelles fonctionnalités nécessitant des transactions complexes ou des données organisées différemment.

  • Limites de la matérialisation des données : utile lorsqu’elle est optimisée pour une tâche unique, mais elle peut poser problème lors de l’ajout de fonctionnalités qui exigent des transactions complexes ou de nouvelles structures de données.

• Prétendre que cela a été prouvé avec un « client Mastodon à l’échelle de Twitter » est impossible, à moins d’exploiter réellement un site web avec 40 millions d’utilisateurs par jour.

  • Importance de l’échelle : il est impossible de simuler un environnement réellement massif, et difficile de soutenir une telle affirmation.

• Une meilleure approche est la combinaison de l’event sourcing et des vues matérialisées.

  • Combinaison de l’event sourcing et des vues matérialisées : présentée comme une meilleure approche, même si elle s’accompagne d’une complexité accrue.

• Un modèle de données unique ne peut pas prendre en charge tous les cas d’usage.

  • Diversité des modèles de données : il est impossible qu’un seul modèle de données couvre tous les cas d’usage.

• Je n’ai rien contre les bases de données.

  • Validité des bases de données : il n’y a pas de reproche envers les bases de données, qui restent des outils pertinents.

• Des concepts comme la concurrence, l’isolation ou les contraintes ont-ils été oubliés ? La « topologie de requêtes » est-elle réellement supérieure pour l’environnement de développement ?

  • Questionnement sur la topologie de requêtes : des notions importantes comme la concurrence, l’isolation et les contraintes semblent absentes, et l’idée que la topologie de requêtes serait supérieure pour l’environnement de développement est remise en question.

• J’ai besoin d’une explication ELI5 de Rama. La documentation est confuse, et merci d’éviter les mots à la mode comme « changement de paradigme » ou « plateforme ».

  • Demande d’explication simple sur Rama : demande d’une explication claire et facile à comprendre sur Rama, sans jargon marketing.

• L’event sourcing (+ vues matérialisées et index) ne signifie pas abandonner le RDBMS. On peut utiliser les deux ensemble.

  • Coexistence entre event sourcing et RDBMS : l’event sourcing et les vues matérialisées peuvent être utilisés avec un RDBMS ; les deux ne s’excluent pas.

Connaissances de base :

• Event Sourcing : modèle de conception qui enregistre les changements d’état d’un système sous forme d’événements, permettant de reconstruire l’état du système en les rejouant.
• Vues matérialisées (Materialized Views) : technique qui stocke physiquement le résultat d’une requête de base de données afin d’améliorer les performances en lecture.
• RDBMS (Relational Database Management System) : système de gestion de bases de données relationnelles.