Les arbres B et autres structures de données deviendront-ils obsolètes avec l'avènement des disques SSD?

De nombreuses applications de bases de données (peut-être la plupart?) Utilisent aujourd'hui des arborescences B et des variantes pour stocker des données, car cette structure de données optimise les opérations de lecture, d'écriture et de recherche sur un disque dur (et ces opérations jouent à leur tour un rôle important dans l'efficacité globale de les bases de données).

Les disques SSD devraient-ils complètement remplacer les disques durs traditionnels (HDD), cependant, pourrait-on dire que les arbres B et les variantes deviendront obsolètes, laissant la place à des structures de données plus efficaces fonctionnant sur la mémoire à accès direct? Si oui, quelles seront ces structures? (par exemple, tables de hachage, arbres AVL)

database data-structures

— Daniel Scocco
source

Demandez-vous s'ils deviendront obsolètes du point de vue de la mise en œuvre de la base de données ou en général parce qu'ils ont beaucoup d'autres applications en dehors des applications de base de données.

— Pemdas

Du point de vue de la base de données.

— Daniel Scocco

Réponses:

Les B-Trees sont le plus souvent utilisés pour les index de base de données sur le disque dur, mais ils présentent des avantages même en tant que structure de données en mémoire, compte tenu de l'hérarchie de la mémoire moderne avec plusieurs couches de cache et de mémoire virtuelle. Même si la mémoire virtuelle est sur un SSD, cela ne changera pas.

J'utilise une bibliothèque d'arborescence multi-voies de style B + en mémoire que j'ai beaucoup écrite en C ++. Il peut avoir des avantages en termes de performances - la raison pour laquelle il a été écrit à l'origine était d'essayer de mieux utiliser le cache - mais je dois admettre qu'il ne fonctionne pas souvent de cette façon. Le problème est le compromis qui signifie que les éléments doivent se déplacer dans les nœuds lors des insertions et des suppressions, ce qui ne se produit pas pour les arbres binaires. En outre, certains des hacks de codage de bas niveau que j'ai utilisés pour l'optimiser - eh bien, ils confondent et défont probablement l'optimiseur, a dit la vérité.

Quoi qu'il en soit, même si vos bases de données sont stockées sur un SSD, il s'agit toujours d' un périphérique de stockage orienté bloc, et il y a toujours un avantage à utiliser les arborescences B et d'autres arborescences multivoies.

MAIS il y a une dizaine d'années, des algorithmes et des structures de données sans cache ont été inventés. Ceux-ci sont inconscients de la taille et de la structure des caches, etc. - ils font (asymptotiquement) la meilleure utilisation possible de toute hiérarchie de la mémoire. Les B-Trees doivent être "accordés" à une hiérarchie de mémoire particulière pour en faire le meilleur usage (bien qu'ils fonctionnent assez bien pour un éventail assez large de variations).

Les structures de données inconscientes du cache ne sont pas encore souvent vues dans la nature, voire pas du tout, mais il est temps qu'elles rendent les arbres binaires en mémoire obsolètes. Et ils peuvent également s'avérer utiles pour les disques durs et les SSD, car ils ne se soucient pas de la taille de la page de la taille du cluster ou du cache du disque dur.

La disposition de Van Emde Boas est très importante dans les structures de données sans cache.

Le cours sur les algorithmes MIT OpenCourseware comprend une certaine couverture des structures de données inconscientes du cache.

— Steve314
source

Intéressant. Vous avez donné de bons conseils (sans jeu de mots!) Pour approfondir ce sujet. Merci.

— Daniel Scocco

Ce cours MIT contient également des informations sur les structures de données inconscientes du cache.

— dan_waterworth

Salut, vouliez-vous dire que B-tree sera obsolète, à cause des structures de données sans cache, pas à cause des SSD? Mais qu'en est-il des autres structures de données, comme la gestion des blocs dans un SGBD?

— Yang Bo

@ user955091 - Je voulais dire à cause des structures de données sans cache (ce qui signifie de façon pédante des structures optimales dans le modèle sans cache), mais j'étais un peu surexcité à leur sujet à l'époque. D'autres structures de données ne vont pas disparaître de si tôt. D'une part, le cache n'est pas le seul problème de performances - le parallélisme fait des demandes différentes. En outre, la commande par clé est souvent un cas spécial - normalement, les tables de hachage sont roi. Il peut être difficile de voir une mise en page "aléatoire" comme compatible avec le cache, mais un accès pour récupérer directement l'élément est difficile à battre - vous n'avez pas besoin de localité.

— Steve314

A priori, oui, la plupart des moteurs de base de données devront être réécrits car le B-Tree ne sera plus la structure de données la plus efficace pour stocker les données, étant donné que la localité est très importante dans un disque dur où le disque se déplace lentement et les données sont récupérées en blocs, ce qui signifie que toute modification des données doit:

Déplacez la tête au bon emplacement sur le disque (~ 10 ms).
Attendez que le disque tourne (à 10 000 tr / min, cela signifie 167 rotations par seconde, mais en moyenne, nous n'attendons qu'une demi-rotation, donc ~ 3 ms).
Lisez le bloc (~ 3 ms).
Modifiez dans la RAM. (~ 10ns)
Déplacez à nouveau la tête au bon endroit sur le disque (~ 10 ms à nouveau).
Attendez que le disque tourne à nouveau (~ 3 ms à nouveau).
Écrivez le bloc (~ 3 ms).

C'est 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

En moyenne, faire la même chose sur un SSD n'est que de 1 ms, quelle que soit la position sur le disque.

Et comme une table de hachage est beaucoup plus rapide, nous pourrions penser qu'une table de hachage serait un meilleur remplacement.

Le seul problème est que les tables de hachage ne préservent pas l'ordre et qu'il n'est donc pas possible de trouver le suivant et le précédent comme le fait Van Emde Boas.

Voir:

Pourquoi trouver le suivant et le précédent est important? Imaginez que tous les éléments soient supérieurs à x et inférieurs à z, vous devez utiliser des index avec find previous et find next.

Eh bien, le seul problème est que nous n'avons pas trouvé de tables de hachage avec des capacités de conservation de l'ordre. Peut-être que la taille du compartiment dans l'arborescence B sera importante, mais cela est résolu avec des algorithmes de cache inconscients.

Je dirais donc que c'est un problème ouvert.

— Wilhelm Van Ende Boas
source

Une table de hachage est (normalement) sans cache WRT modélisant ses performances, mais cela ne signifie pas qu'elle est efficace dans ce modèle. Le problème est que les fonctions de hachage sont normalement conçues pour disperser des éléments "au hasard" - c'est pourquoi les tables de hachage ne sont pas ordonnées et aussi pourquoi elles ont une mauvaise localisation. Cela signifie que même si vous pouvez identifier une séquence d'éléments avec des clés adjacentes, il est peu probable que vous profitiez de la lecture de deux éléments ou plus par bloc (les SSD sont toujours des périphériques de bloc).

— Steve314

De hashing cours est aussi parfois appelée « transformation clé » et la transformation de ne pas avoir à être « au hasard » - il est peut - être possible de définir une fonction de hachage qui permet un accès séquentiel raisonnablement efficace (pas d' éliminer la recherche - l' information est perdue par la la fonction de hachage, après tout, mais en la minimisant) et donne des avantages locaux tout en gardant les collisions de hachage rares.

— Steve314