Arbre noir rouge contre arbre B
J'ai un projet dans lequel je dois effectuer des opérations rapides de recherche, d'insertion et de suppression sur des données allant de mégaoctets à téraoctets. J'avais récemment étudié et analysé les structures de données. Étant spécifique, je veux présenter 3 cas et poser des questions à ce sujet:
Les données représentent bien plus que ce que la mémoire peut gérer (plages d'échantillons comprises entre 10 et 15 téraoctets) en une fois. Dans ce cas, je stockerais la structure de données sur un disque.
Les données sont relativement moins comparées à la mémoire du système et peuvent donc être stockées et utilisées dans la mémoire elle-même pour plus de rapidité.
Les données représentent davantage que de la mémoire libre et supposent qu’elles sont inférieures à la taille d’un bloc de données contigu possible dans le fichier de pagination. ainsi je stocke la structure de données dans un fichier sur disque et fais un mappage de la mémoire du fichier.
Les conclusions que j'ai tirées sont:
Pour le cas 1, je devrais utiliser un B-Tree pour un accès plus rapide, car cela évite les retards produits par la rotation du disque
Dans le cas 2, je devrais utiliser un arbre rouge noir pour un accès plus rapide car les données sont en mémoire et non. Dans le pire des cas, le nombre d'éléments à analyser serait inférieur à celui que je devrais faire si j'utilisais des arbres B
Pour le cas 3, je doute que celui-ci, le fichier de la page sur disque utilise les E/S natives du système d'exploitation pour fonctionner sur les fichiers. B Tree devrait-il être une meilleure option ou un arbre rouge noir?
Je veux savoir où les trois conclusions ci-dessus vont bien et où cela ne va pas et comment je peux améliorer les performances dans les trois cas distincts.
J'utilise le langage C++, avec un arbre noir rouge et un arbre B, les deux que j'ai conçus à partir de zéro. J'utilise la bibliothèque Boost pour le mappage de fichiers.
Mise à jour 1 :: Était en train de lire this post dans stackoverflow. J'ai de très bonnes idées, ce qui me fait penser que le type de comparaison que j'ai effectué dans les cas peut être défectueux. Un lien a été publié dans le forum le plus voté http://idlebox.net/2007/stx-btree/stx-btree-0.8.3/doxygen-html/speedtest.html
Un arbre rouge/noir est plus ou moins équivalent à un arbre 2-3-4, qui n’est qu’un type d’arbre en B. Les performances les plus défavorables sont identiques, à condition que vous effectuiez une recherche binaire des valeurs du nœud B-tree.
L'inconvénient évident d'un arbre B est le gaspillage d'espace, mais en fonction de l'allocateur de langue/mémoire utilisé, vous constaterez peut-être qu'un arbre 2-3-4 utilise moins d'espace qu'un arbre rouge-noir en moyenne. Par exemple, en Java 32 bits, il existe une surcharge d'environ 8 octets par objet. (Cela dépend aussi beaucoup de l'allocateur; phkmalloc de l'IIRC arrondit les petites allocations à une taille de puissance égale à 2.)
Pour répondre à vos cas,
- La latence du disque est répartie à peu près également entre le temps de recherche et l’attente de la rotation du disque.
- Un arbre B devrait pouvoir surperformer un arbre rouge-noir si vous le faites bien (en particulier, un arbre B devrait être plus rapide si les nœuds entrent dans une ligne de cache.)
- Il n'est pas nécessaire qu'il soit contigu dans le fichier de page; il doit simplement être contigu dans l'espace d'adressage virtuel du processus. Pour les systèmes d’exploitation rationnels, il est également pratiquement identique au cas 1, à moins que vos données ne soient suffisamment petites pour qu’elles tiennent la plupart du temps dans la mémoire et que la surcharge de mémoire soit importante.
Pour plus de simplicité, j'utiliserais un arbre B et exécuterais des tests de performances sur différentes tailles de nœuds.
Pour comprendre la différence entre ceux-ci, lisez ci-dessous 2 points:
1) Un "arbre rouge-noir" est un "arbre de recherche binaire" "auto-équilibrant", , Chaque nœud étant marqué d'une couleur (rouge ou noire) et comportant des opérations supplémentaires à conserver " équilibre"
2) Tous les "arbres rouges-noirs" sont des "arbres de recherche binaires", mais tous les "arbres de recherche binaires" ne sont pas des "arbres rouges-noirs"