Gli alberi B e altre strutture di dati diventeranno obsoleti con l'avvento delle unità a stato solido?

Molte applicazioni di database (forse la maggior parte?) Oggi usano alberi B e variazioni per archiviare i dati, poiché questa struttura di dati ottimizza le operazioni di lettura, scrittura e ricerca su un disco rigido (e queste operazioni a loro volta svolgono un ruolo importante nell'efficienza complessiva di i database).

Tuttavia, Solid State Drives (SSD) dovrebbe superare completamente i tradizionali hard disk (HDD), potremmo dire che gli alberi B e le variazioni diventeranno obsoleti, dando spazio a strutture di dati più efficienti che operano sulla memoria ad accesso diretto? In tal caso, quali saranno tali strutture? (ad es. tabelle hash, alberi AVL)

database data-structures

— Daniel Scocco
fonte

Stai chiedendo se diventeranno obsoleti dal punto di vista dell'implementazione del database o in generale perché hanno molte altre applicazioni al di fuori delle applicazioni di database.

— Pemdas,

Dal punto di vista del database.

— Daniel Scocco,

Risposte:

Gli alberi B sono spesso usati per gli indici di database sul disco rigido, ma presentano vantaggi anche come struttura di dati in memoria, data la moderna gerarchia della memoria con più livelli di cache e memoria virtuale. Anche se la memoria virtuale si trova su un SSD, ciò non cambierà.

Uso una libreria ad albero multiway in stile B + in memoria che ho scritto parecchio in C ++. Si può avere vantaggi di prestazioni - la ragione per cui è stato originariamente scritto è stato quello di provare ad usare la cache meglio - ma devo ammettere che spesso non funziona in questo modo. Il problema è il compromesso, il che significa che gli elementi devono spostarsi all'interno dei nodi su inserti ed eliminazioni, il che non accade per gli alberi binari. Inoltre, alcuni degli hack di codifica di basso livello che ho usato per ottimizzarlo - probabilmente confondono e sconfiggono l'ottimizzatore, ha detto la verità.

Ad ogni modo, anche se i tuoi database sono archiviati su un SSD, questo è ancora un dispositivo di archiviazione orientato ai blocchi, e c'è ancora un vantaggio nell'uso di B-Trees e altri alberi multiway.

MA circa dieci anni fa sono stati inventati algoritmi e strutture di dati ignari della cache. Questi sono ignari delle dimensioni e della struttura delle cache, ecc. - fanno (asintoticamente) il miglior uso possibile di qualsiasi erirarchia della memoria. Gli alberi B devono essere "sintonizzati" su una particolare gerarchia di memoria per sfruttare al meglio (anche se funzionano abbastanza bene per una vasta gamma di variazioni).

Le strutture di dati ignari della cache non sono spesso viste allo stato brado, se non del tutto, ma a volte potrebbero rendere obsoleti i soliti alberi binari in memoria. E possono anche rivelarsi utili anche per dischi rigidi e SSD, poiché non si preoccupano delle dimensioni della pagina della cache del cluster o del disco rigido.

Il layout di Van Emde Boas è molto importante nelle strutture di dati ignari della cache.

Il corso sugli algoritmi OpenCourseware del MIT include una certa copertura delle strutture di dati ignari della cache.

— Steve314
fonte

Interessante. Hai fornito alcuni buoni suggerimenti (nessun gioco di parole previsto!) Per esplorare ulteriormente questo argomento. Grazie.

— Daniel Scocco,

Questo corso del MIT contiene anche informazioni sulle strutture di dati ignari della cache.

— dan_waterworth,

Ciao, intendevi dire che B-tree sarebbe obsoleto, a causa delle strutture di dati ignari della cache, non a causa degli SSD? Ma che dire di altre strutture di dati, come la gestione dei blocchi in un DBMS?

— Yang Bo,

@ user955091 - Intendevo a causa delle strutture di dati ignari della cache (che significano strutture pedanticamente ottimali nel modello ignaro della cache), ma all'epoca ero un po 'troppo eccitato. Altre strutture di dati non scompariranno presto. Per prima cosa, la cache non è l'unico problema di prestazioni: il parallelismo richiede esigenze diverse. Inoltre, la necessità di ordinare in base alle chiavi è spesso un caso speciale - normalmente, le tabelle hash sono re. Può essere difficile vedere un layout "randomizzato" come cache-friendly, ma un accesso per recuperare direttamente l'elemento è difficile da battere - non hai bisogno di località.

— Steve314

A priori, sì, la maggior parte dei motori di database dovrà essere riscritta poiché il B-Tree non sarà più la struttura di dati più efficiente per archiviare i dati, dato che la località è tutto importante in un disco rigido in cui il disco si sposta lentamente e i dati vengono recuperati in blocchi, il che significa che qualsiasi modifica ai dati deve:

Spostare la testa nella posizione corretta sul disco (~ 10ms).
Aspetta che il disco ruoti (a 10k rpm, ciò significa 167 rotazioni al secondo, ma in media aspettiamo solo mezza rotazione, quindi ~ 3ms).
Leggi il blocco (~ 3ms).
Modifica in RAM. (~ 10ns)
Spostare di nuovo la testa nella posizione corretta sul disco (di nuovo ~ 10 ms).
Attendere che il disco ruoti di nuovo (~ 3ms di nuovo).
Scrivi il blocco (~ 3ms).

Sono 10 + 3 + 3 + 10 + 3 + 3 = 34 ms

In media, fare lo stesso su un SSD è solo 1ms, indipendentemente dalla posizione sul disco.

E poiché una tabella hash è molto più veloce, potremmo pensare che una tabella hash sarebbe una migliore sostituzione.

L'unico problema è che gli hashtable non mantengono l'ordine e quindi non è possibile trovare il prossimo e il precedente come fa Van Emde Boas.

Vedere:

Perché trovare il prossimo e il precedente è importante? Immagina di ottenere tutti gli elementi più grandi di x e più piccoli di z, devi usare gli indici con find precedente e find successivo.

Bene, l'unico problema è che non abbiamo trovato hashtable con capacità di preservare l'ordine. Forse la dimensione del bucket nell'albero B sarà importante, ma ciò verrà risolto con algoritmi ignari della cache.

Quindi direi che questo è un problema aperto.

— Wilhelm Van Ende Boas
fonte

Una tabella hash è (normalmente) cache WRT ignara che modella le sue prestazioni, ma ciò non significa che sia efficiente in quel modello. Il problema è che le funzioni hash sono normalmente progettate per disperdere gli oggetti "casualmente" - ecco perché le tabelle hash non sono ordinate e anche perché hanno una localizzazione scadente. Ciò significa che anche se è possibile identificare una sequenza di elementi con chiavi adiacenti, è improbabile che si tragga beneficio dalla lettura di due o più elementi per blocco (gli SSD sono ancora dispositivi a blocchi).

— Steve314,

Ovviamente l'hash è talvolta chiamato anche "trasformazione chiave" e la trasformazione non deve essere "casuale" - forse è possibile definire una funzione hash che consenta un accesso sequenziale ragionevolmente efficiente (non eliminando la ricerca - le informazioni vengono perse dal funzione hash, dopotutto, ma minimizzandola) e offre alcuni vantaggi in termini di località mantenendo comunque rare le collisioni di hash.

— Steve314,