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


15

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)


Você está perguntando se eles se tornarão obsoletos do ponto de vista da implementação do banco de dados ou, em geral, porque existem muitos outros aplicativos fora dos aplicativos de banco de dados.
pemdas

Do ponto de vista do banco de dados.
quer

Respostas:


21

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.


1
Interessante. Você deu boas dicas (sem trocadilhos!) Para explorar esse tópico ainda mais. Obrigado.
precisa

Este curso do MIT também possui informações sobre estruturas de dados alheios ao cache.
dan_waterworth

Oi, você quis dizer que a árvore B será obsoleta por causa de estruturas de dados que não fazem cache, e não por SSDs? Mas e outras estruturas de dados, como gerenciamento de blocos em um DBMS?
Yang Bo

@ user955091 - Eu quis dizer por causa de estruturas de dados que ignoram o cache (significando pedantemente estruturas que são ótimas no modelo que ignoram o cache), mas eu estava um pouco excitado demais com elas na época. Outras estruturas de dados não desaparecerão tão cedo. Por um lado, o cache não é o único problema de desempenho - o paralelismo faz demandas diferentes. Além disso, a necessidade de pedidos com base em chaves geralmente é um caso especial - normalmente, as tabelas de hash são importantes. Pode ser difícil ver um layout "aleatório" como compatível com o cache, mas é difícil vencer um acesso para buscar diretamente o item - você não precisa de localidade.
Steve314

3

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.


Uma tabela de hash é (normalmente) o WRT inconsciente do cache, modelando seu desempenho, mas isso não significa que seja eficiente nesse modelo. O problema é que as funções de hash normalmente são projetadas para dispersar os itens "aleatoriamente" - é por isso que as tabelas de hash não são ordenadas e também porque elas têm uma localidade ruim. Isso significa que, mesmo que você consiga identificar uma sequência de itens com chaves adjacentes, é improvável que você se beneficie da leitura de dois ou mais itens por bloco (os SSDs ainda são dispositivos de bloco).
Steve314

1
É claro que o hash também é chamado de "transformação de chave" e a transformação não precisa ser "aleatória" - talvez seja possível definir uma função de hash que permita acesso seqüencial razoavelmente eficiente (não eliminando a pesquisa - as informações são perdidas pelo a função hash, afinal - mas minimizá-la) e oferece alguns benefícios de localidade, mantendo as colisões de hash raras.
precisa saber é o seguinte
Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.