Quali sono le implicazioni dell'uso dell'SSD sulle ipotesi fondamentali del database?

Question

Gli SSD sono ormai comuni; Amazon EBS è supportato da SSD, quindi la maggior parte dei database cloud ora funziona anche su SSD (Heroku PostgreSQL, ecc.). I database e le architetture correlate sono state progettate tradizionalmente con l'idea che l'accesso casuale sia negativo, non è più il caso degli SSD.

In che modo gli SSD influiscono su quanto segue?

1. Progettazione database: i DB sono progettati per ridurre al minimo la ricerca di dischi (WAL, alberi B). In che modo gli SSD modificano i componenti interni e l'ottimizzazione di un progetto DB?
2. Sviluppo di applicazioni - L'ipotesi di lavoro è sempre stata che (a) che si desidera richiedere gli utenti del server a memoria, senza DB, e (2) che l'accesso al DB è legato IO. Con gli SSD, il recupero dei dati dal DB può essere abbastanza veloce e l'accesso al DB è spesso legato alla rete. Questo riduce la necessità di database in memoria? Ovviamente si vuole ancora pre-elaborazione operazioni costose, ma è potenzialmente in grado semplicemente archiviarli in un database specializzati DB
3. - Ci sono un bel paio di DB che fanno cose che relazionale DB sono supponiamo di essere male (in parte a causa della accesso casuale ai dati). Uno di questi esempi sono i DB grafici (Neo4j) che memorizzano i nodi e gli elenchi di adiacenze sul disco in modo compatto. Questi database sono utili se possiamo implementare un RDBMS su SSD e non preoccuparci dell'accesso casuale?

Answer 1

In primo luogo, gli SSD non fanno accesso casuale gratuito. Più economico. In particolare, le scritture casuali scrivono rimangono molto costose, sebbene ciò sia attenuato in piccole scritture casuali da parte di una cache di write-back durevole.

WAL sarebbe molto costoso su SSD se la SSD veramente lavata ai media sottostanti - ma non è così. Lo accumula nella cache di write-back e periodicamente lo scarica in blocchi di dimensioni di blocchi interi. Quindi WAL funziona davvero molto bene su SDD, in quanto non c'è mai bisogno di un ciclo di lettura/modifica/scrittura per una scrittura a blocchi di cancellazione parziale.

Sono sicuro che ci sono opportunità per essere avuto nella struttura di stoccaggio struttura per gli indici su SSD. Non è ancora qualcosa che abbiamo già studiato in PostgreSQL.

maggior parte dei server DB SSD basati su cui lavoro rimangono a fondo disco I/O bound per il funzionamento normale. Gli SSD sono veloci, ma non magici. Anche gli SSD integrati PCI-E non possono competere con la RAM, e grandi carichi di lavoro tendono a saturare rapidamente la cache e le code di write back dell'SSD. Allo stesso modo, camminare su una lista di adiacenze in un RDBMS è ancora lontano dai termini computazionali, la rappresentazione su disco è meno compatta che in un DB grafico, ecc. C'è molto da guadagnare dalla specializzazione dove ne hai bisogno.

Per guardare veramente a cosa serve l'archiviazione ultraveloce per i DB, è necessario fare un passo avanti e guardare i dispositivi di archiviazione basati su RAM PCIe che sono incredibilmente, incredibilmente veloci.

BTW, in molti modi un SSD non è diverso da un HBA SCSI con una cache di scrittura con batteria tampone. Questi sono stati in giro per molto tempo. Un SSD tenderà ad avere letture casuali migliori, ma è comunque abbastanza simile.