¿Se volverán obsoletos los árboles B y otras estructuras de datos con la llegada de las unidades de estado sólido?

Muchas aplicaciones de bases de datos (¿quizás la mayoría?) Hoy en día usan B-Trees y variaciones para almacenar datos, porque esta estructura de datos optimiza las operaciones de lectura, escritura y búsqueda en un disco duro (y estas operaciones a su vez juegan un papel importante en la eficiencia general de las bases de datos)

Sin embargo, ¿deberían las unidades de estado sólido (SSD) superar completamente a los discos duros tradicionales (HDD)? ¿Podríamos decir que los B-Trees y las variaciones se volverán obsoletos, dando lugar a estructuras de datos que funcionan de manera más eficiente en la memoria de acceso directo? Si es así, ¿cuáles serán esas estructuras? (por ejemplo, tablas hash, árboles AVL)

Los B-Trees se usan con mayor frecuencia para los índices de bases de datos en el disco duro, pero tienen ventajas incluso como una estructura de datos en memoria, dada la jerarquía de memoria moderna con múltiples capas de caché y con memoria virtual. Incluso si la memoria virtual está en un SSD, eso no cambiará.

Utilizo una biblioteca de árbol de múltiples vías estilo B + en memoria que escribí bastante en C ++. Se puede tener ventajas de rendimiento - la razón por la que fue escrito originalmente era tratar de utilizar la memoria caché mejor - pero tengo que admitir que a menudo no funciona de esa manera. El problema es la compensación, lo que significa que los elementos deben moverse dentro de los nodos en las inserciones y eliminaciones, lo que no ocurre con los árboles binarios. Además, algunos de los hacks de codificación de bajo nivel que utilicé para optimizarlo, bueno, probablemente confunden y derrotan al optimizador, la verdad es que.

De todos modos, incluso si sus bases de datos se almacenan en un SSD, ese sigue siendo un dispositivo de almacenamiento orientado a bloques, y todavía hay una ventaja de usar B-Trees y otros árboles de múltiples vías.

PERO hace unos diez años, se inventaron algoritmos y estructuras de datos ajenos al caché. Estos son ajenos al tamaño y la estructura de los cachés, etc. - hacen (asintóticamente) el mejor uso posible de cualquier jerarquía de memoria. Los árboles B deben "ajustarse" a una jerarquía de memoria particular para hacer el mejor uso (aunque funcionan bastante bien para una amplia gama de variaciones).

Las estructuras de datos ajenas a la memoria caché a menudo aún no se ven en la naturaleza, si es que lo hacen, pero es hora de que hagan obsoletos los árboles binarios en memoria habituales. Y también pueden resultar útiles para discos duros y SSD, ya que no les importa cuál es el tamaño del clúster o el tamaño de la página de caché del disco duro.

El diseño de Van Emde Boas es muy importante en las estructuras de datos ajenas a la memoria caché.

El curso de algoritmos MIT OpenCourseware incluye cierta cobertura de estructuras de datos ajenos a la memoria caché.

A priori, sí, la mayoría de los motores de bases de datos tendrán que reescribirse ya que B-Tree ya no será la estructura de datos más eficiente para almacenar datos, dado que la localidad es muy importante en un disco duro donde el disco se mueve lentamente y se obtienen datos en bloques, lo que significa que cualquier cambio en los datos debe:

1. Mueva la cabeza a la ubicación correcta en el disco (~ 10 ms).
2. Espere a que el disco gire (a 10k rpm, eso significa 167 rotaciones por segundo, pero en promedio solo esperamos media rotación, entonces ~ 3 ms).
3. Lea el bloque (~ 3 ms).
4. Modificar en RAM. (~ 10ns)
5. Mueva la cabeza a la ubicación correcta en el disco nuevamente (~ 10 ms nuevamente).
6. Espere a que el disco gire nuevamente (~ 3 ms nuevamente).
7. Escribe el bloque (~ 3 ms).

Eso es 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

En promedio, hacer lo mismo en un SSD es de solo 1 ms, independientemente de la posición en el disco.

Y dado que una tabla hash es mucho más rápida, podríamos pensar que una tabla hash sería un mejor reemplazo.

El único problema es que las tablas hash no preservan el orden y, por lo tanto, no es posible encontrar el siguiente y el anterior como hace Van Emde Boas.

Ver:

1. http://en.wikipedia.org/wiki/Van_Emde_Boas_tree
2. http://bryanpendleton.blogspot.com/2009/06/cache-oblivious-data-structures.html

¿Por qué encontrar siguiente y anterior es importante? Imagina que todos los elementos son más grandes que x y más pequeños que z, debes usar índices con find previous y find next.

Bueno, el único problema es que no hemos encontrado tablas hash con habilidades para preservar el orden. Tal vez el tamaño del cubo en el árbol B será importante, pero eso se resuelve con algoritmos ajenos a la memoria caché.

Entonces diría que este es un problema abierto.