In MySQL, un tipo di indice è un b-tree e l'accesso a un elemento in un b-tree è in tempo ammortizzato logaritmico O(log(n)).
D'altra parte, l'accesso a un elemento in una tabella hash è in O(1).
Perché non viene utilizzata una tabella hash al posto di un b-tree per accedere ai dati all'interno di un database?
Risposte:
Puoi accedere agli elementi solo tramite la loro chiave primaria in una tabella hash. Questo è più veloce che con un algoritmo ad albero ( O(1)invece dilog(n) ), ma non puoi selezionare intervalli ( tutto ciò che si trova tra xey ). Gli algoritmi ad albero lo supportano Log(n)mentre gli indici hash possono provocare una scansione completa della tabella O(n). Anche il sovraccarico costante degli indici hash è solitamente maggiore ( che non è un fattore nella notazione theta, ma esiste ancora ). Anche gli algoritmi ad albero sono generalmente più facili da mantenere, crescere con i dati, scalare, ecc.
Gli indici hash funzionano con dimensioni hash predefinite, quindi si finisce con alcuni "bucket" in cui sono archiviati gli oggetti. Questi oggetti vengono ripetuti in loop per trovare davvero quello giusto all'interno di questa partizione.
Quindi, se si dispone di dimensioni ridotte, si ha molto sovraccarico per elementi piccoli, dimensioni grandi comportano un'ulteriore scansione.
Gli algoritmi delle tabelle hash di oggi di solito vengono ridimensionati, ma il ridimensionamento può essere inefficiente.
Esistono infatti algoritmi di hashing scalabili. Non chiedermi come funziona, è un mistero anche per me. AFAIK si sono evoluti dalla replica scalabile in cui il re-hashing non è facile.
Si chiama RUSH - R eplication U nder S calable H ashing, e quegli algoritmi sono quindi chiamati algoritmi RUSH.
Tuttavia, potrebbe esserci un punto in cui il tuo indice supera una dimensione tollerabile rispetto alle dimensioni hash e l'intero indice deve essere ricostruito. Di solito questo non è un problema, ma per database enormi, enormi, questo può richiedere giorni.
Il compromesso per gli algoritmi ad albero è piccolo e sono adatti per quasi tutti i casi d'uso e quindi sono predefiniti.
Tuttavia, se hai un caso d'uso molto preciso e sai esattamente cosa e solo cosa sarà necessario, puoi sfruttare gli indici di hashing.
In realtà, sembra che MySQL utilizzi entrambi i tipi di indici o una tabella hash o un b-tree secondo il seguente link .
La differenza tra l'utilizzo di un albero b e di una tabella hash è che la prima consente di utilizzare confronti di colonne in espressioni che utilizzano gli operatori =,>,> =, <, <= o BETWEEN, mentre la seconda viene utilizzata solo per confronti di uguaglianza che utilizzano gli operatori = o <=>.
La complessità temporale delle tabelle hash è costante solo per tabelle hash di dimensioni sufficienti (devono essere presenti intervalli sufficienti per contenere i dati). La dimensione di una tabella di database non è nota in anticipo, quindi la tabella deve essere modificata di tanto in tanto per ottenere prestazioni ottimali da una tabella hash. Anche il rimaneggiamento è costoso.
Penso che gli hashmap non si scalino altrettanto bene e possono essere costosi quando l'intera mappa deve essere modificata.
Pick DB / OS era basato sull'hashing e funzionava bene. Con più memoria in questi giorni per supportare tabelle hash sparse efficienti e hashing ridondante per supportare query di intervallo modesto, direi che l'hashing potrebbe ancora avere il suo posto (alcuni preferirebbero avere altre forme di corrispondenza della somiglianza non di intervallo, come i caratteri jolly e le espressioni regolari ). Si consiglia inoltre di copiare per mantenere le catene di collisioni contigue quando le gerarchie di memoria presentano grandi differenze di velocità.