Perché NoSQL è più veloce di SQL?

48

Di recente mi è stato chiesto:

Perché NoSQL è più veloce di SQL?

Non ero d'accordo con la premessa della domanda ... è solo una sciocchezza per me personalmente. Non riesco a vedere alcun aumento delle prestazioni utilizzando NoSQL anziché SQL. Forse SQL su NoSQL, sì, ma non in questo modo.

Mi sto perdendo qualcosa su NoSQL?

performance nosql

— CND
fonte

3

Se non riesci a vedere un aumento delle prestazioni, questo è quello che dici. Il fatto è che la maggior parte delle soluzioni NoSQL rinuncia a una (o più) delle proprietà ACID di un database relazionale, quindi fanno di meno.

— Oded,

1

Esistono alcuni flussi di lavoro (e strutture di dati) che non possono essere facilmente associati a un database relazionale abilitato per ACID tradizionale. Per quelli, puoi vedere enormi aumenti delle prestazioni usando un database NoSQL. Se, tuttavia, si prende semplicemente un DB SQL esistente (ben progettato) e lo si inserisce in un database NoSQL, le prestazioni ne risentiranno sicuramente .

— Joachim Sauer,

1

La risposta è: è stato stabilito come più veloce? E più veloce in cosa? Tempo di sviluppo? Tempo per leggere? Scrivere tempo? Quale tipo di scrittura? A cosa lo stiamo confrontando? Query multi-tavolo? Si unisce?

— Rolf,

65

Ci sono molte soluzioni NoSQL in giro, ognuna con i suoi punti di forza e di debolezza, quindi le seguenti devono essere prese con un granello di sale.

Ma essenzialmente, ciò che fanno molti database NoSQL è affidarsi alla denormalizzazione e cercare di ottimizzare il caso denormalizzato. Ad esempio, supponiamo che stai leggendo un post sul blog insieme ai suoi commenti in un database orientato ai documenti. Spesso i commenti vengono salvati insieme al post stesso. Ciò significa che sarà più veloce recuperarli tutti insieme, poiché sono memorizzati nello stesso posto e non è necessario eseguire un join.

Ovviamente, puoi fare lo stesso in SQL e la denormalizzazione è una pratica comune quando si ha bisogno di prestazioni. È solo che molte soluzioni NoSQL sono progettate fin dall'inizio per essere sempre utilizzate in questo modo. Quindi si ottengono i soliti compromessi: ad esempio, l'aggiunta di un commento nell'esempio sopra sarà più lenta perché è necessario salvare l'intero documento con esso. E una volta denormalizzato, devi occuparti di preservare l'integrità dei dati nella tua applicazione.

Inoltre, in molte soluzioni NoSQL, è impossibile eseguire join arbitrari, quindi query arbitrarie. Alcuni database, come CouchDB, richiedono di pensare in anticipo alle query necessarie e prepararle all'interno del DB.

Tutto sommato, si riduce a prevedere uno schema denormalizzato e ad ottimizzare le letture per quella situazione, e questo funziona bene per i dati che non sono altamente relazionali e che richiedono molte più letture che scritture.

— Andrea
fonte

4

Questo, a proposito, può essere realizzato con una semplice visualizzazione materializzata, o un livello di cache, pur beneficiando di tutta la bontà di SQL. Qualunque cosa modellata correttamente è relazionale e la duplicazione logica dei dati non è una soluzione (la vista mat è una duplicazione ma non una duplicazione logica perché è semplicemente un'immagine di qualcos'altro).

— Morg.

Come ho detto nella risposta, si può fare lo stesso in SQL; è solo che quando questa diventa la regola anziché l'eccezione, i database NoSQL sono in genere più veloci e più naturali da usare. In teoria, SQL è il modello migliore che si possa usare, ma quando i dati crescono oltre una certa dimensione, non possono adattarsi ad alcuni modelli e la duplicazione dei dati diventa più veloce e più facile da ragionare.

— Andrea,

3

Questo è toro. Il modello relazionale copre tutto ciò che puoi fare in NoSQL e molto altro ancora. L'unico vantaggio di NoSQL è che un approccio al ridimensionamento semplice e incoerente è integrato e facile da usare. Non ha nulla a che fare con SQL e tutto ha a che fare con il non preoccuparsi delle proprietà ACID. Puoi avere processi di sincronizzazione tra nodi SQL indipendenti che avranno esattamente le stesse (molto cattive) proprietà di ridimensionamento e coerenza degli archivi NoSQL. La differenza è che i nodi SQL possono anche avere coerenza se lo si sceglie.

— Morg.

1

Che cosa succede se si dispone di 5.000.000 milioni di righe di dati e si desidera ottenere il commento da tutti a una condizione. Non sarebbe più veloce se avessi un indice nel campo dei commenti della tabella con SQL? L'indicizzazione full-text migliorerebbe ulteriormente questo aspetto.

— jwize,

@morg - "Il modello relazionale copre tutto ciò che puoi fare in NoSQL e molto altro ancora." Non proprio no. Esistono molti esempi di tipi di dati che si adattano in modo così inadeguato al modello relazionale che forzare i dati in esso risulta in una grave inefficienza. Esempio: un gioco online ha una funzione per conservare l'inventario dei giocatori. I giocatori hanno una serie finita di slot numerati, ognuno dei quali può memorizzare uno o più oggetti di un tipo specifico. Ci sono circa 50 diversi tipi di oggetti, ognuno dei quali ha 4-6 attributi associati, con alcune sovrapposizioni, quindi ci sono circa 80 possibili attributi ...

— Jules

27

La cosa che ti manca di NoSQL è che NoSQl non può essere paragonato a SQL in alcun modo. NoSQL è il nome di tutte le tecnologie di persistenza che non sono SQL. DB di documenti, DB di valori-chiave, DB di eventi sono tutti NoSQL. Sono tutti diversi in quasi tutti gli aspetti, sia che si tratti di struttura di dati salvati, query, prestazioni e strumenti disponibili.

Quindi, se qualcuno ti pone tale domanda al colloquio, questa dovrebbe essere la risposta.

— Euforico
fonte

4

Se c'è una caratteristica killer di NoSQL, direi che è la scalabilità. Ecco perché lo usano Facebook e Google. A causa del gigantesco volume di dati. NoSQL: quando devi gestire enormi quantità di dati.

— Pieter B,

16

I database 'NoSQL' (o più precisamente: non relazionali) rinunciano ad alcune funzionalità dei database tradizionali per la velocità, ma soprattutto per la scalabilità orizzontale.

Le funzioni mancanti dipendono dal prodotto concreto, in generale le proprietà ACID complete o anche le operazioni di join non sono supportate. Questo è il prezzo per l'aumento delle prestazioni.

— Karl
fonte

1

Descrivere NoSQL come non relazionale non è più preciso. Esistono altri vecchi DB non relazionali che non rientrano nella categoria NoSQL. NoSQL significa molto di più di un semplice non relazionale. Leggi questo per ulteriori informazioni: martinfowler.com/bliki/NosqlDefinition.html

— eddyP23

8

Hai ragione, sarebbe una sciocchezza affermarlo in una dichiarazione generale. Quale è probabilmente il punto intero; invece di una singola risposta, l'intervistatore probabilmente si aspetta che tu risponda con domande per aiutarti a capire quale sia il contesto del problema (che tipo di dati, quanto di esso, in quale ambiente operativo ecc.), la particolare soluzione NoSQL . Proveranno a scoprire come si analizzano i problemi e lungo la strada farsi un'idea di quanto si conoscono le diverse soluzioni disponibili.

— Eelco
fonte

Sì, è un'affermazione generale e se accettiamo che sia vera, allora la risposta alla domanda è: dipende.

— Rolf,

5

I database NoSQL hanno normalmente senso solo se si progettano i dati intorno a loro.

Se si intende semplicemente utilizzarli come sostituti RDBMS, è possibile che si ottengano meno prestazioni anziché maggiori, soprattutto se non si dispone di budget sufficiente per pagare server con elevate quantità di RAM.

Guarda questo articolo che confronta l'utilizzo dello spazio su disco MySQL con quello di MongoDB: http://blog.trackerbird.com/content/mysql-vs-mongodb-disk-space-usage

— Clifford
fonte

3

Quale database NoSQL? Quale database SQL? Se qualcuno ti dice che NoSQL è più veloce di SQL, allora dovresti andartene. O meglio ancora guarda questo video:

http://www.youtube.com/watch?v=b2F-DItXtZs

Non dirò che metà delle cose sostenute su NoSQL sono sbagliate, ma dirò che c'è un sacco di fanboyismo NoSQL là fuori da persone che davvero non lo capiscono molto bene.

SQL ha i suoi limiti (ovviamente) ma è anche una tecnologia molto matura, che è ben compresa, e ha un ampio pool di sviluppatori che capiscono come usarlo bene. Non posso dire lo stesso per tutte le forme di NoSQL.

— Zachary K
fonte

-2

NoSql supportato da database orientati alle colonne in cui RDBMS è un database orientato alle righe ... E diciamo ad esempio che abbiamo una tabella Employee con nome, età, saleria, indirizzo, EmployeeId ecc ... abbiamo messo la stessa tabella in MySql (supporto RDBMS) e HBase (Supporto NoSQL). Se un cliente / cliente scrive una query per ottenere i dati medi sull'età o sulla saleria dai record dei dipendenti di 1Lakh ... cosa succede?

In RDBMS andrà in giro per ogni riga e raccoglierà il valore e la somma e la divisione per il risultato. Quando si tratta di database Columnar, non è necessario preoccuparsi di tutte le iterazioni di una riga lakh. Ma gestisci solo una riga che è più veloce da calcolare. Quindi in questo modo a volte NoSQL è più veloce di SQL. Questo caso a NoSQL non importa dei reclami ACID vale la pena!

— kiran teja avvaru
fonte

2

Ho risolto un po 'la formulazione, anche se non sono sicuro di cosa stai cercando di ottenere tra i due. E ACID non è sempre supportato da RDBMS.

-3

Dimentica la teoria sui database .... il punto una volta che hai capito le tue query, puoi salvare i dati nei database nosql in un modo esatto in cui sono effettivamente utilizzati nella tua applicazione ....

Ad esempio, prendi questo esempio, hai un modello di cliente con molti ordini e molti articoli associati a ciascun ordine, quindi hanno anche molti articoli salvati per acquisti successivi ... se sei un grande negozio di e-commerce con diciamo 10 milioni di clienti e 50 milioni di ordini. E quel cliente accede alla sua dashboard che mostra questi dati esatti, quanto lavoro dovrà fare un database sql per trovare il cliente, unire gli ordini e ciascun elemento pubblicitario e gli elementi salvati. In un database sql probabilmente tutti questi dati dovranno essere uniti in qualche modo ... oppure puoi creare una raccolta nel tuo database chiamato usercache e salvare questi dati esattamente come li usi nella vita reale. Quindi questa può davvero essere una singola query su un singolo campo [id] per recuperare tutti questi dati. Inoltre, il database nosql non funziona

Quindi un database sql può interrogare un singolo campo ID altrettanto velocemente se non più velocemente di nosql? Sì, ma un database sql può restituire tutti i dati necessari interrogando una tabella e un campo? No, a meno che tu non faccia qualcosa come salvare i dati in Json all'interno di un grande campo di testo. Ma ora che i dati non sono in grado di eseguire query per un potenziale utilizzo futuro.

— Steffan Perry
fonte