Perché la coppia di valori chiave noSQL db è più veloce dei DB relazionali tradizionali

Question

Mi è stato consigliato di esaminare i sistemi di dati coppia chiave/valore per sostituire un database relazionale che ho utilizzato.

Quello che non capisco è come questo migliori l'efficienza delle query. Da quello che ho capito, stai buttando via molte informazioni che potrebbero aiutare a rendere le query più efficienti, semplicemente trasformando il tuo database di strutture in una lunga lista di chiavi e valori?

Ho perso completamente il punto?

Answer 1

Il vantaggio principale di un database relazionale è la capacità di correlare e indicizzare le informazioni. La maggior parte dei sistemi 'NoSQL' non fornisce un'algebra relazionale o un ottimo linguaggio di interrogazione.

Quello che devi chiederti è, la commutazione ha senso per il mio caso d'uso previsto?

Hai perso il punto. Il punto è che a volte non hai un indice (nel modo in cui lo fai con un DB relazionale generale comunque). Anche quando hai un indice, la capacità di metterlo insieme è difficile e su quali basi di dati relazionali eccellono. Le soluzioni NoSQL hanno una serie di nuove strutture che rendono banalmente facili molti casi di utilizzo, ad es. Redis è un DB orientato alla struttura dati adatto per la creazione rapida di qualsiasi cosa con le code o la sua architettura pub-sub. MongoDB è un database di documenti a forma libera che archivia documenti come JSON (BSON) ed eccelle in rapido sviluppo. Le soluzioni BigTable sono un po 'meno strutturate, ma amplia l'idea di una riga per avere famiglie di colonne - coppie di valori chiave contenute in ogni riga disposte in modo efficiente su disco. Puoi costruire un indice invertito con una tecnologia come ElasticSearch.

Non tutto ha bisogno delle garanzie di coerenza o del layout del disco di un RDBMS tradizionale. Un altro importante caso d'uso di NoSQL è la massiccia scalabilità, molte soluzioni (ad es. BigTable - HBase/Cassandra) sono progettate per dividere e ridimensionare in orizzontale facilmente (non così facile con SQL!). Cassandra in particolare è progettato senza SPOF. Inoltre, i datastore orientati alle colonne sono pensati per ottimizzare le velocità del disco tramite letture sequenziali (e ridurre write-amplification). Detto questo, a meno che non ne abbia davvero bisogno, un server SQL tradizionale è generalmente abbastanza buono.

Ci sono vantaggi e svantaggi. Personalmente, uso un mix di entrambi. Utilizzare lo strumento giusto per il lavoro giusto, che può finire per essere PostgreSQL o MySQL il più delle volte.

È possibile associare un sistema di valori-chiave di base a una tabella SQL con due colonne, una chiave univoca e un valore. Questo è abbastanza veloce. Non hai bisogno di fare alcuna relazione o correlazione o raccolta di dati. Basta trovare il valore e restituirlo. Questa è una semplificazione eccessiva, i database NoSQL hanno molte funzionalità e applicazioni interessanti oltre ai semplici negozi K, V.

Non so se i dati scientifici siano adatti alla maggior parte delle implementazioni NoSQL, che dipendono dai dati. Se guardi HBase o Cassandra, potrebbe adattarsi alle esigenze di uno scienziato (con una corretta progettazione di riga di comando - il timestamp non deve essere il primo, controlla OpenTSDB). Conosco molte aziende che memorizzano le letture dei sensori in Cassandra utilizzando un partizionatore casuale per ordine e l'UUID del sensore per riportare le letture in file di grassi giornalieri. Ogni giorno vengono creati nuovi database intorno a casi d'uso specifici, in modo che la risposta possa cambiare. Per casi d'uso specifici, è possibile ottenere enormi vantaggi per l'utilizzo di datastore specifici a spese di flessibilità e strumenti.

Answer 2

L'efficienza proviene da tre aree principali:

1. Il database ha molte meno funzioni: esiste il concetto di un join e requisiti di integrità transazionale attenuate o assenti. Meno funzioni significa meno lavoro significa più veloce, almeno dal lato server.
2. Un altro principio di progettazione è che l'archivio dati risiede in una nuvola di server in modo che la richiesta possa avere più rispondenti. Questi sistemi affermano inoltre che il sistema multi-server migliora la tolleranza agli errori attraverso la replica.
3. È pienamente conforme alle parole d'ordine, utilizzando un gruppo di idee e descrizioni che non sono ancora state completamente inventate. Ad esempio, Amazon sta attualmente offrendo i propri servizi per capire meglio come le persone potrebbero usarli e acquisire esperienza per perfezionare le specifiche.

Ai miei occhi, qualcuno che viene a voi con un requisito che "i nostri nuovi dati saranno troppo per i nostri RDBMS" dovrebbe o hanno i numeri per eseguire tale affermazione o ammettere vogliono solo provare il nuovo lucido. NoSQL è senza merito? Probabilmente no. Farà capovolgere il mondo quando è stato lanciato Java 1.0? Probabilmente no.

Non c'è nulla di male nell'indagare su cose nuove, basta non scommettere la fattoria su di loro a favore di una tecnologia vecchia di 50 anni, ben consolidata e ben compresa.

Answer 3

Qui sto assumendo che si desidera ottimizzare una query particolare, che è semplicemente guardando un record per chiave. Un esempio di questo potrebbe essere la ricerca di un record userinfo per nome utente. Per alcuni sistemi una query del genere deve essere incredibilmente veloce e tutte le altre query non sono importanti.

Il più grande fattore nelle prestazioni del database sarà il numero di operazioni di I/O richieste per leggere/scrivere dati. La maggior parte dei sistemi di database utilizza strutture dati simili (ad esempio b-tree) che possono trasferire dati non archiviati in I/O (log (n)). Per fornire aggiornamenti durevoli, i dati dovranno essere scritti su disco: la maggior parte dei sistemi lo fa in modo sequenziale, il che è il modo più veloce.

Quindi, dove può un rendimento di un negozio Key-Value?

1. Dati non normalizzati. Mettere tutti i dati in una riga significa non avere join.
2. Overhead CPU basso. Un archivio valore-chiave evita il costo della CPU per l'elaborazione/ottimizzazione della query, i controlli di sicurezza, i controlli dei vincoli, ecc.
3. È più semplice avere lo store in-process (a differenza di un server SQL in esecuzione come servizio separato) questo elimina il sovraccarico IPC.

La maggior parte dei sistemi RDBMS è costruita su qualcosa che sembra un archivio di valori-chiave in modo da poterlo visualizzare come se fosse un intermediario.

Answer 4

Ci sono molte buone osservazioni sopra e qualche volta un po 'troppa passione da entrambe le parti da parte di entrambi i proponenti. Torniamo alla tua domanda iniziale. Supponiamo che tu faccia un disegno su Cassandra e faccia un disegno identico su un RDBMS. Supponi di avere un set di coppie KV in Cassandra e di fare un insieme identico di coppie KV su relazionale. (In realtà è possibile farlo - ad esempio, come una coppia valore nome completamente denormalizzata su relazionale). Anche così, relazionale verrà eseguito più lentamente semplicemente a causa del sovraccarico del DBMS relazionale - registrazione, accesso al catalogo, controllo dell'integrità, atomicità delle transazioni, ecc. Inoltre, nell'archivio dei dati della famiglia di colonne i dati vengono ordinati in modo lessicale. non è in relazione. Credo che molti dei social network abbiano fatto questo, hanno costruito strutture identiche su entrambi, ma la relazione è stata più lenta.È importante ricordare che dopo che un utente ha interrogato il database del prodotto, guarda chi ha comprato questo o quello, costruisce il carrello e la loro lista dei desideri, il tutto sarà fatto su NOSQL, quando l'utente preme il pulsante checkout, la transazione verrà eseguito su un database relazionale. Perché non possiamo dire che gli esperti si rendono conto che non è l'uno contro l'altro in questo dibattito sui database, ma piuttosto che c'è un posto relazionale, come c'è per NOSQL, grafico, database di colonne invertite, multidimensionale, ecc. File.