As árvores B e outras estruturas de dados se tornarão obsoletas com o advento das unidades de estado sólido?

Atualmente, muitos aplicativos de banco de dados (talvez a maioria?) Usam B-Trees e variações para armazenar dados, porque essa estrutura de dados otimiza as operações de leitura, gravação e busca em um disco rígido (e essas operações, por sua vez, desempenham um papel importante na eficiência geral do os bancos de dados).

No entanto, os discos de estado sólido (SSDs) substituem completamente os discos rígidos tradicionais (HDDs), poderíamos dizer que as árvores B e as variações se tornarão obsoletas, dando espaço para estruturas de dados mais eficientes que operam na memória de acesso direto? Em caso afirmativo, quais serão essas estruturas? (por exemplo, tabelas de hash, árvores AVL)

As árvores B são usadas com mais freqüência para índices de banco de dados no disco rígido, mas possuem vantagens mesmo como uma estrutura de dados na memória, dada a hierarquia de memória moderna com várias camadas de cache e memória virtual. Mesmo se a memória virtual estiver em um SSD, isso não mudará.

Eu uso uma biblioteca de múltiplas árvores no estilo B + na memória que escrevi bastante em C ++. Ele pode ter vantagens de desempenho - a razão pela qual foi originalmente escrito foi para tentar usar melhor o cache - mas devo admitir que muitas vezes não funciona dessa maneira. O problema é o trade-off, o que significa que os itens precisam se mover dentro dos nós nas inserções e exclusões, o que não acontece nas árvores binárias. Além disso, alguns dos hacks de código de baixo nível que eu usei para otimizá-lo - bem, eles provavelmente confundem e derrotam o otimizador, disse a verdade.

De qualquer forma, mesmo que seus bancos de dados estejam armazenados em um SSD, ele ainda é um dispositivo de armazenamento orientado a blocos e ainda há uma vantagem em usar B-Trees e outras árvores com várias vias.

MAS, cerca de dez anos atrás, foram inventados algoritmos e estruturas de dados que ignoravam o cache. Eles são alheios ao tamanho e à estrutura dos caches, etc. - eles fazem (assintoticamente) o melhor uso possível de qualquer hierarquia de memória. As árvores B precisam ser "ajustadas" a uma hierarquia de memória específica para fazer o melhor uso (embora funcionem razoavelmente bem para uma ampla variedade de variações).

As estruturas de dados inconscientes do cache ainda não são vistas na natureza, se é que existem, mas é hora de tornarem obsoletas as árvores binárias comuns da memória. E eles também podem ser úteis para discos rígidos e SSDs, já que não se importam com o tamanho da página do cache do cluster ou do disco rígido.

O layout do Van Emde Boas é muito importante em estruturas de dados que não fazem parte do cache.

O curso de algoritmos do MIT OpenCourseware inclui alguma cobertura das estruturas de dados alheios ao cache.

A priori, sim, a maioria dos mecanismos de banco de dados terá que ser reescrita, pois o B-Tree não será mais a estrutura de dados mais eficiente para armazenar dados, dado que a localidade é muito importante em um disco rígido em que o disco se move lentamente e os dados são buscados em blocos, o que significa que qualquer alteração nos dados precisa:

1. Mova a cabeça para o local correto no disco (~ 10 ms).
2. Aguarde o disco girar (a 10k rpm, o que significa 167 rotações por segundo, mas, em média, esperamos apenas meia rotação, aproximadamente 3ms).
3. Leia o bloco (~ 3ms).
4. Modifique na RAM. (~ 10ns)
5. Mova a cabeça para o local certo no disco novamente (~ 10 ms novamente).
6. Aguarde o disco girar novamente (~ 3 ms novamente).
7. Escreva o bloco (~ 3ms).

Isso é 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

Em média, fazer o mesmo em um SSD é de apenas 1ms, independentemente da posição no disco.

E como uma hashtable é muito mais rápida, poderíamos pensar que uma hashtable seria uma substituição melhor.

O único problema é que as tabelas de hash não preservam a ordem e, portanto, não é possível encontrar o próximo e o anterior, como Van Emde Boas faz.

Vejo:

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

Por que encontrar o próximo e o anterior é importante? Imagine obter todos os elementos maiores que x e menores que z, você precisa usar índices com find previous e find next.

Bem, o único problema é que não encontramos hashtables com capacidade de preservar a ordem. Talvez o tamanho do bucket na árvore B seja importante, mas isso é resolvido com algoritmos alheios ao cache.

Então, eu diria que este é um problema em aberto.