Gli SSD riducono l'utilità dei database


28

Ho sentito parlare solo di Robert Martin oggi, e sembra che sia una figura di spicco nel mondo del software, quindi non intendo che il mio titolo appaia come se fosse un clic o se gli mettessi delle parole in bocca, ma questo è semplicemente come ho interpretato ciò che ho sentito da lui con la mia limitata esperienza e comprensione.

Oggi stavo guardando un video (sull'architettura del software), su un discorso di Robert C. Martin, e nella seconda metà del video, l'argomento dei database era il focus principale.

Dalla mia comprensione di ciò che ha detto, sembrava che stesse dicendo che gli SSD ridurranno l'utilità dei database ( considerevolmente ).

Per spiegare come sono arrivato a questa interpretazione:

Ha discusso di come, con HDD / dischi rotanti, il recupero dei dati sia lento. Tuttavia, in questi giorni usiamo SSD, ha osservato. Comincia con "La RAM sta arrivando" e poi continua citando i dischi RAM, ma poi dice che non può chiamarlo disco RAM, quindi ricorre solo a dire RAM. Quindi, con la RAM, non abbiamo bisogno degli indici, perché ogni byte impiega lo stesso tempo per ottenere. ( questo paragrafo è parafrasato da me )

Quindi, lui suggerisce che la RAM (come nella memoria del computer) come un sostituto per i DB (dato che è quello che ho interpretato la sua affermazione come) non ha senso perché è come dire che tutti i record sono elaborati in memoria nella vita di un'applicazione ( a meno che non si estrae da un file su disco su richiesta)

Quindi, ho fatto ricorso al pensiero di RAM, intende SSD. Quindi, in quel caso, sta dicendo che gli SSD riducono l'utilità dei database. Dice anche "Se fossi Oracle, avrei paura. La vera base del perché esisto sta evaporando".

Dalla mia scarsa comprensione degli SSD, a differenza degli HDD, che sono O(n)tempi di ricerca (penso), gli SSD sono vicini O(1)o quasi casuali. Quindi, il suo suggerimento è stato interessante per me, perché non ci ho mai pensato in quel modo. La prima volta che sono stato introdotto ai database alcuni anni fa, quando un professore stava descrivendo i vantaggi rispetto al normale filesystem, ho concluso che il ruolo principale di un database è essenzialmente quello di essere un filesystem molto indicizzato (oltre a ottimizzazioni, memorizzazione nella cache, accesso simultaneo, ecc.), quindi, se non sono necessari indici in SSD, questo tipo di database rende meno utili.

Indipendentemente da ciò, tuttavia, prima di essere un newb, trovo difficile credere che diventino meno utili, poiché tutti usano ancora i DB come punto principale della loro applicazione, invece del puro filesystem, e si sentono come se stesse semplificando troppo il ruolo dei database.

Nota : ho guardato fino alla fine per assicurarmi che non avesse detto qualcosa di diverso.

Per riferimento: 42:22 è quando viene visualizzato l'intero argomento del database, 43:52 è quando inizia con "Perché abbiamo persino dei database"

Questa risposta dice che gli SSD velocizzano notevolmente i DB. Questa domanda chiede come viene modificata l'ottimizzazione.

A TL; DR, la mia domanda, l'avvento dell'uso diffuso di SSD nel mercato dei server (sia che sia imminente o sia già accaduto) riduce l'utilità dei database?

Sembrava che ciò che il presentatore stesse cercando di comunicare fosse che con gli SSD si possono archiviare i dati su disco e non doversi preoccupare di quanto sarebbe lento recuperarli come con gli HDD più vecchi, come con gli SSD, i tempi di ricerca sono vicini O(1)(Credo). Quindi, nel caso in cui ciò fosse vero, ciò ipoteticamente perderebbe uno dei vantaggi che aveva: l'indicizzazione, perché il vantaggio di avere indici per tempi di ricerca più rapidi è sparito.

Risposte:


59

Ci sono alcune cose in un database che dovrebbero essere modificate quando si usano SSD. Ad esempio, parlando per PostgreSQL è possibile regolare effective_io_concurrencye random_page_cost. Tuttavia, letture più rapide e un accesso casuale più rapido non sono ciò che fa un database. Assicura

Ha solo torto sugli indici. Se l'intera tabella può essere letta in ram, un indice è comunque utile. Non mi credi? Facciamo un esperimento mentale,

  • Immagina di avere una tabella con una colonna indicizzata.

    CREATE TABLE foobar ( id text PRIMARY KEY );
  • Immagina che ci siano 500 milioni di righe in quella tabella.

  • Immagina che tutti i 500 milioni di righe siano concatenati insieme in un file.

Cosa c'è più veloce,

  1. grep 'keyword' file
  2. SELECT * FROM foobar WHERE id = 'keyword'

Non si tratta solo di dove si trovano i dati, ma di come li ordini e quali operazioni puoi eseguirli. PostgreSQL supporta gli indici B-tree, Hash, GiST, SP-GiST, GIN e BRIN (e Bloom tramite un'estensione). Saresti sciocco a pensare che tutta quella matematica e funzionalità scompaiano perché hai un accesso casuale più veloce.


31
Solo un addendum - OP dovrebbe fare attenzione a non confondere "accesso casuale" con "accesso indirizzabile al contenuto". Come notato da OP, "accesso casuale" significa che raggiungere ogni byte di memoria è O (1). Tuttavia, TROVARE i dati in quella "memoria ad accesso casuale" richiede ancora una ricerca sequenziale attraverso di essa; cioè, non puoi chiedere alla memoria "trovami i dati che assomigliano a questo " e fatti consegnare magicamente a te.
Bob Jarvis - Ripristina Monica il

2
@BobJarvis Hai ragione. Il tuo commento aiuta a chiarire ancora di più l'esempio "Cosa c'è di più veloce" di EvanCarroll sul perché l'indicizzazione e persino la sottoindicizzazione contano, e il solo accaparrarsi O(1)non è sufficiente per i casi d'uso forniti da un DB
Abdul

12

Sulla base del tuo post, sembra che il messaggio chiaro sia che le ottimizzazioni del tempo di ricerca RDBMS vengono sostituite con hardware che rende il tempo di I / O trascurabile.

Questo è assolutamente vero. L'SSD sui server di database combinato con una RAM (effettiva) elevata riduce notevolmente le attese di IO. Tuttavia, l'indicizzazione e la memorizzazione nella cache di RDBMS sono ancora utili perché anche i sistemi con questo enorme vantaggio IO possono e avranno colli di bottiglia di IO da query con scarse prestazioni causate da una cattiva indicizzazione. Questo si trova in genere solo in applicazioni con carichi di lavoro elevati o in applicazioni scarsamente scritte.

Il valore chiave per i sistemi RDBMS in generale è la coerenza, la disponibilità e l'aggregazione dei dati. L'uso di un foglio di calcolo Excel, un file CSV o un altro metodo per mantenere una "base di dati" non fornisce garanzie.

SSD non ti protegge dal tuo server primario non disponibile per nessun motivo (rete, danneggiamento del sistema operativo, perdita di potenza). SSD non ti protegge da una modifica errata dei dati. SSD non rende più veloce l'esecuzione dell'analisi rispetto al "solo fatto".


Anche se ho acquisito una visione migliore, stavo chiedendo nel contesto della memorizzazione dei dati SSD grezzi rispetto alla memorizzazione dei dati su un DB con HDD, e la tua risposta è nel contesto di DB su SSD (a causa della scarsa espressione delle mie domande)
Abdul,

4
@Abdul Questo confronto riguarda i ponti dalle mele alle sospensioni. Un dispositivo raw ti offre una grande estensione di archiviazione; un database ti offre un modo per organizzare e accedere a tale memoria in base a un modello di dati. Il punto di Josh qui è che se vai in questo con l'idea dagli occhi stellati che un SSD grezzo è una cosa meravigliosa perché è "veloce" e che stai per scrivere codice per fare tutto il tuo archivio di dati su quel volume grezzo , finirai per scrivere un database.
Blrfl,

8

Lo zio Bob probabilmente stava parlando di database in memoria come Redis o Gemfire . In questi database, tutto nel database è veramente contenuto nella RAM. Il database potrebbe iniziare vuoto ed essere archiviato con dati di breve durata (utilizzato come cache) oppure iniziare caricando tutto dal disco e controllando periodicamente le modifiche al disco.

Questo sta diventando sempre più popolare perché la RAM sta diventando economica e diventa possibile avere un terabyte di dati archiviati in un database cluster in memoria. Ci sono molti casi d'uso in cui la velocità di accesso istantaneo alle cose rende prezioso inserire la RAM piuttosto che un disco veloce come SSD. Puoi anche continuare a utilizzare SQL per alcuni di questi, se ha senso.

Perché questo dovrebbe preoccupare Oracle? I dati stanno crescendo ed è improbabile che gli RDBMS scompaiano. Tuttavia, nel corso degli anni, gran parte del tempo di ingegnerizzazione di Oracle è andato in vari modi per velocizzare il recupero dei dati sui dischi rotanti. Oracle dovrà adattarsi a un livello di archiviazione completamente diverso. Lo sono, con Oracle Database In Memory , ma sono esposti a una concorrenza diversa rispetto al passato. Pensa a quanto tempo è passato per assicurarti che Query Optimizer scelga le giuste strategie in base al layout delle cose sul disco ....


Ah. Non ho mai saputo cose come i database in memoria
Abdul,

1
Come altro esempio SQLite può essere eseguito in memoria, quindi non è necessario utilizzare un database diverso
user151019

8

Il post Wiki della community che raccoglie le risposte originariamente lasciato come commenti alle domande


Direi esattamente il contrario. Poiché le velocità di lettura / scrittura sono così elevate, ora è possibile ottenere un database con accelerazione GPU (ad esempio BlazingDB o Alenka ) per sgretolare i numeri ancora più velocemente. Ora puoi avere query ancora più complesse più veloci. Ora le query che le persone non prenderebbero nemmeno in considerazione la corsa possono essere eseguite a una velocità ragionevole. Più sono complessi e più sono i dati, meglio sei: cybernard

Mentre Bob Martin è in circolazione da molto tempo e le sue opinioni in genere meritano di essere ascoltate (se non d'accordo con :-), in questo caso penso che si sta tuffando nella folla "La morte dei database relazionali è su di noi" (di cui Sono un membro associato :-). Per alcune cose, in circostanze limitate, si può argomentare in qualche modo convincente che le tecnologie di database non relazionali possono offrire un vantaggio. Detto questo, tuttavia, IMO il modello relazionale, imperfetto in vari e vari modi, può ancora fornire il miglior modello di database per scopi generici oggi disponibile. YMMV. - Bob Jarvis

Il motivo principale per cui utilizziamo i database non è perché i dischi sono lenti (in effetti, in origine, è stato citato come motivo per non utilizzare i database), ma piuttosto perché i dati sono complicati . Lo scopo principale di un database è consentire a più app / utenti di essere in grado di trovare i dati corretti e persino di essere in grado di modificarli contemporaneamente in modo controllato. Farlo rapidamente è solo un obiettivo secondario dei database. - RBarryYoung

RDBMS non scomparirà presto; sono la scelta migliore per alcuni tipi di applicazione e NoSQL (Mongo, ecc.) è la scelta migliore per altri. Cavalli per i corsi. - sh1rts

Il database aiuta a organizzare i dati. In realtà, in primo luogo non è stato progettato per un rapido accesso ai dati. - JI Xiang

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.