B-Tree vs Hash Table

No MySQL, um tipo de índice é uma árvore b, e o acesso a um elemento em uma árvore b é em tempo amortizado logarítmico O(log(n)).

Por outro lado, acessar um elemento em uma tabela hash está em O(1).

Por que uma tabela hash não é usada em vez de uma árvore b para acessar dados dentro de um banco de dados?

Você só pode acessar elementos por sua chave primária em uma tabela de hash. Isso é mais rápido do que com um algoritmo de árvore (em O(1)vez delog(n) ), mas você não pode selecionar intervalos ( tudo entre xey ). Algoritmos de árvore suportam isso, Log(n)enquanto os índices hash podem resultar em uma varredura completa da tabela O(n). Além disso, a sobrecarga constante dos índices hash geralmente é maior (o que não é um fator na notação teta, mas ainda existe ). Além disso, os algoritmos de árvore são geralmente mais fáceis de manter, aumentar com os dados, escalar, etc.

Os índices de hash funcionam com tamanhos de hash predefinidos, então você acaba com alguns "depósitos" onde os objetos são armazenados. Esses objetos são repetidos novamente para realmente encontrar o correto dentro desta partição.

Portanto, se você tiver tamanhos pequenos, terá muita sobrecarga para elementos pequenos, os tamanhos grandes resultarão em varreduras adicionais.

Os algoritmos das tabelas de hash atuais geralmente são escalonados, mas o escalonamento pode ser ineficiente.

De fato, existem algoritmos de hash escalonáveis. Não me pergunte como isso funciona - é um mistério para mim também. AFAIK eles evoluíram da replicação escalável, onde o re-hashing não é fácil.

É denominado RUSH - R eplication U nder S calable H ashing , e esses algoritmos são chamados de algoritmos RUSH.

No entanto, pode haver um ponto em que seu índice excede um tamanho tolerável em comparação com os tamanhos de hash e todo o índice precisa ser reconstruído. Normalmente, isso não é um problema, mas para bancos de dados enorme, enorme, isso pode levar dias.

A troca de algoritmos de árvore é pequena e eles são adequados para quase todos os casos de uso e, portanto, são padrão.

No entanto, se você tiver um caso de uso muito preciso e souber exatamente o que e apenas o que será necessário, poderá aproveitar as vantagens dos índices de hash.

Na verdade, parece que o MySQL usa ambos os tipos de índices, uma tabela hash ou uma árvore b de acordo com o link a seguir .

A diferença entre usar uma árvore b e uma tabela hash é que a primeira permite que você use comparações de coluna em expressões que usam os operadores =,>,> =, <, <= ou BETWEEN, enquanto a última é usada apenas para comparações de igualdade que usam os operadores = ou <=>.

A complexidade de tempo de hashtables é constante apenas para hashtables de tamanho suficiente (é necessário haver baldes suficientes para armazenar os dados). O tamanho de uma tabela de banco de dados não é conhecido com antecedência, portanto, a tabela deve ser refeita de vez em quando para obter o desempenho ideal de uma tabela de hash. A reformulação também é cara.

Acho que os Hashmaps não escalam tão bem e podem ser caros quando o mapa inteiro precisa ser refeito.

Pick DB / OS foi baseado em hash e funcionou bem. Com mais memória hoje em dia para suportar tabelas de hash esparsas eficientes e hash redundante para suportar consultas de intervalo modesto, eu diria que o hash ainda pode ter seu lugar (alguns preferem ter outras formas de correspondência de similaridade sem intervalo, como curingas e regexps ) Também recomendamos copiar para manter as cadeias de colisão contíguas quando as hierarquias de memória têm grandes diferenças de velocidade.