Abandonner le modèle relationnel, c’est “réinventer la roue” • The Register

Enregistrer le débat Bienvenue à nouveau dans le dernier débat sur les registres dans lequel les écrivains discutent de sujets technologiques et vous, le lecteur, choisissez l’argument gagnant.

Le format est simple : nous proposons une motion, les arguments pour la motion ont couru lundi et aujourd’hui, et les arguments contre mardi et demain. Au cours de la semaine, vous pouvez voter pour quel côté vous soutenez en utilisant le sondage intégré ci-dessous, en choisissant si vous êtes pour ou contre. Le score final sera annoncé vendredi, révélant quel argument était le plus populaire.

C’est à nos rédacteurs de vous convaincre de voter pour leur camp.

La motion de cette semaine est :

Les bases de données de graphes – dans lesquelles les relations sont stockées de manière native avec les éléments de données – n’offrent pas un avantage significatif par rapport aux bases de données relationnelles bien architecturées pour la plupart des mêmes cas d’utilisation.

Argumentant POUR la motion une fois de plus, avec un contrepoint aux affirmations d’hier de Jim Webber, est Andy Pavloprofesseur agrégé de base de données à l’Université Carnegie Mellon.

Tout n’est qu’amusement et jeux jusqu’à ce que les choses deviennent … Relationnel

Mon estimé collègue est timide en affirmant qu’il ne sait pas ce que signifie un SGBD “bien architecturé”. Permettez-moi néanmoins de lui rappeler les principales caractéristiques d’un tel système. Je me concentrerai sur les requêtes analytiques sur les graphes, car c’est ce que les SGBD graphes prétendent être meilleurs que les SGBD relationnels. Ma liste ci-dessous s’en inspire également Article CIDR 2023 [PDF] par des chercheurs de CWI.

1. Analyses rapides sur des données typées – Le mouvement NoSQL a induit les développeurs en erreur en pensant qu’une base de données sans schéma (c’est-à-dire avec schéma facultatif) est une bonne idée. Cela est nécessaire pour certains scénarios, et la plupart des SGBD relationnels prennent désormais en charge les types de données JSON. Mais pour extraire rapidement les données, si le SGBD connaît le schéma et les types de données, il supprime l’indirection et améliore les performances d’analyse.
2. Columnar Storage – Stockage des données dans un manière orientée colonne présente plusieurs avantages, notamment la réduction des E/S disque et de la surcharge de mémoire en raison du saut de colonnes inutiles pour une requête. Les données en colonnes ont également une entropie plus faible que les données orientées lignes, ce qui les rend plus faciles à schémas de compression qui ne nécessitent pas que le SGBD le décompresse au préalable.
3. Exécution de requête vectorisée – Utilisation d’un modèle de traitement vectorisé [PDF] (par opposition à un modèle tuple à la fois) améliore les performances du SGBD pour les requêtes analytiques de 10 à 100 fois. Le traitement des données par lots permet également au SGBD de tirer parti instructions CPU vectorisées (SIMD) pour améliorer encore les performances.
4. Contrôle explicite de la mémoire – Le SGBD a besoin d’un contrôle complet sur ses allocations de mémoire. Cela signifie ne pas utiliser un runtime de mémoire “géré” (par exemple, JVM, Erland) où la fragmentation et la récupération de place causeront des problèmes de performances, ni permettre au système d’exploitation de déterminer quelles données expulser du cache (par exemple, MMAP). Le SGBD doit également disposer d’un placement de données précis pour garantir que les informations associées sont situées à proximité les unes des autres afin d’améliorer l’efficacité du processeur.

Il existe quelques optimisations supplémentaires spécifiques aux graphes qu’un SGBD relationnel doit intégrer :

1. API de requête centrées sur les graphes – La norme SQL:2023 introduit Requêtes de graphique de propriétés (SQL/PCG) pour définir et parcourir des graphes dans un SGBD relationnel. SQL/PCG est un sous-ensemble de la norme émergente GQL. Ainsi, SQL/PCG réduit davantage la différence de fonctionnalité entre les SGBD relationnels et les SGBD de graphes natifs.
2. Améliorations de l’exécution des requêtes – Un SGBD relationnel bien architecturé voudra inclure des améliorations spécifiquement pour optimiser les requêtes de graphe, y compris jointures optimales multivoies dans le pire des cas (WCOJ), structures de données éphémères compactes (par exemple, lignes clairsemées compressées), et traitement factorisé des requêtes. Bien que leur ajout nécessite une ingénierie non triviale, de telles améliorations s’intègrent parfaitement aux moteurs d’exécution de SGBD relationnels existants et ne nécessitent pas l’écriture d’un nouveau moteur à partir de zéro.

Comme preuve de la performance d’un SGBD relationnel bien architecturé par rapport à un SGBD graphique, je me réfère au Article CIDR 2023 du CWI [PDF]. Ils ont prolongé la CanardDB SGBD relationnel analytique intégré pour ajouter la prise en charge de SQL/PCG et les améliorations ci-dessus. Ensuite, ils l’ont comparé à un SGBD graphique de premier plan sur une référence graphique standard de l’industrie. Leurs résultats montrent que DuckDB, avec les extensions ci-dessus, surpasse jusqu’à 10 fois le SGBD graphique natif. Ce sont des résultats à la pointe de la technologie datant de janvier 2023 et non d’il y a cinq ans.

Et bien que l’équipe du CWI comprenne certains des meilleurs chercheurs en systèmes de bases de données au monde, ils n’ont pas levé des centaines de millions de dollars pour obtenir ces résultats.

En ce qui concerne la référence de mon collègue à Stonebraker’s article fondateur de 2006 qui réfute les architectures de SGBD “taille unique”, leur anecdote selon laquelle Neo4j est née de leur tentative d’utiliser un SGBD relationnel dans les années 2000 pour les charges de travail centrées sur les graphes est la preuve de l’argument de Stonebraker. Mais l’erreur qu’ils ont commise a été d’ignorer l’historique des bases de données et d’essayer de réinventer la roue en abandonnant le modèle relationnel. J’encourage également les lecteurs intéressés à lire Stonebraker’s traité de 2006 [PDF] sur l’échec des modèles de données alternatifs à supplanter le modèle de données relationnel depuis son invention en 1969. d’autres dans le passé).

Enfin, je maintiens mon Pari public 2021 sur l’avenir du marché des bases de données de graphes. Je remplacerai ma photo officielle CMU par l’une de moi portant une chemise qui dit “Graph Databases Are #1”. J’utiliserai cette photo jusqu’à ce que je prenne ma retraite, me fasse virer ou qu’un ancien élève me poignarde. ®

Votez ci-dessous. Nous clôturerons le sondage jeudi soir et publierons le résultat final vendredi. Vous pouvez suivre l’évolution du débat ici.

Les pages AMP ne prennent pas en charge l’affichage d’un sondage. Voir l’histoire non-AMP à la place.