Perché NoSQL è più veloce di SQL?

Ci sono molte soluzioni NoSQL in giro, ognuna con i suoi punti di forza e di debolezza, quindi il seguente deve essere preso con un pizzico di sale.

In sostanza, ciò che molti database NoSQL fanno è fare affidamento sulla denormalizzazione e cercare di ottimizzare il caso denormalizzato. Ad esempio, supponi di leggere un post sul blog insieme ai suoi commenti in un database orientato ai documenti. Spesso i commenti verranno salvati insieme al post stesso. Ciò significa che sarà più veloce recuperarli tutti insieme, poiché vengono memorizzati nello stesso posto e non è necessario eseguire un join.

Ovviamente, puoi fare lo stesso in SQL, e denormalizzare è una pratica comune quando hai bisogno di prestazioni. È solo che molte soluzioni NoSQL sono progettate sin dall'inizio per essere sempre utilizzate in questo modo. Si ottengono quindi i soliti compromessi: ad esempio, l'aggiunta di un commento nell'esempio precedente sarà più lenta poiché è necessario salvare l'intero documento con esso. E una volta denormalizzato, devi prenderti cura 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 ad aspettarsi 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 rispetto alle scritture.

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, siano essi struttura dei dati salvati, query, prestazioni e strumenti disponibili.

Quindi se qualcuno ti fa questa domanda durante l'intervista, questa dovrebbe essere la risposta.

I database "NoSQL" (o più precisamente: non relazionali) forniscono alcune funzionalità dei database tradizionali per la velocità, ma ancora più importante per la scalabilità orizzontale.

Le funzionalità 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.

Hai ragione, sarebbe assurdo 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 qual è il contesto del problema (che tipo di dati, quanto di esso, in quale ambiente operativo ecc.), la particolare soluzione NoSQL . Cercheranno di scoprire come si analizzano i problemi e lungo la strada avere un'idea di quanto sai sulle diverse soluzioni disponibili.

I database NoSQL normalmente hanno senso solo se progetti i tuoi dati attorno a loro.

Se si intende semplicemente utilizzarli come sostituzione RDBMS, è possibile che si ottengano meno prestazioni anziché più, soprattutto se non si dispone di un 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: link

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

link

Non dirò che la metà delle cose che dicono NoSQL sono sbagliate, ma dirò che c'è un sacco di fanboyism 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 grande pool di sviluppatori che capiscono come usarlo bene. Non posso dire lo stesso per tutte le forme di NoSQL.

NoSql supportato da database orientati alle colonne in cui RDBMS è un database orientato alle righe ... E diciamo per esempio che abbiamo una tabella Employee con Nome, Età, Salery, Indirizzo, EmployeeId ecc ... mettiamo la stessa tabella in MySql (supporto RDBMS ) e HBase (supporto NoSQL). Se un cliente / cliente scrive una query per ottenere i dati di età media o salery da record 1Lakh dipendenti ... cosa succede?

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

Dimentica la teoria intorno ai database .... il punto una volta che hai capito i tuoi querys, puoi salvare i dati nei database nosql in modo esatto in cui sono effettivamente utilizzati nella tua applicazione ....

Ad esempio, prendi questo esempio, hai un modello cliente con molti ordini e molti articoli associati a ciascun ordine, quindi hanno anche molti elementi salvati per acquisti successivi ... se sei un grande negozio di e-commerce con diciamo 10 milioni clienti e 50 milioni di ordini. E quel cliente accede al loro cruscotto che mostra questi dati esatti, quanto lavoro deve fare un database SQL per trovare il cliente, unire gli ordini e ogni elemento pubblicitario e gli elementi salvati. In un database SQL tutti questi dati dovranno probabilmente essere uniti in qualche modo ... o 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 ha bisogno di inviare la query a tutti e 40 i server di database per recuperare le informazioni solo quelle che hanno effettivamente i dati.

Quindi un sql db può interrogare un singolo campo Id altrettanto veloce se non più veloce 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 campo di testo di grandi dimensioni. Ma ora che i dati non sono interrogabili per un possibile uso futuro.