perché i database noSQL sono più scalabili di SQL?

Recentemente ho letto molto sui DBMS noSQL. Comprendo il teorema della CAP , le regole ACID , le regole BASE e la teoria di base. Ma non hai trovato alcuna risorsa sul perché noSQL è scalabile più facilmente di RDBMS (ad esempio nel caso di un sistema che richiede molti server DB)?

Immagino che mantenere vincoli e chiavi esterne costino risorse e quando un DBMS viene distribuito, è molto più complicato. Ma mi aspetto che ci sia molto di più.

Qualcuno può spiegare in che modo noSQL / SQL influisce sulla scalabilità?

I database noSQL rinunciano a una grande quantità di funzionalità che un database SQL offre per sua natura.

Cose come l'applicazione automatica di integrità referenziale, transazioni, ecc. Queste sono tutte cose che sono molto utili per avere alcuni problemi e che richiedono alcune tecniche interessanti per scalare al di fuori di un singolo server (pensa a cosa succede se devi bloccare due tabelle per una transazione atomica e si trovano su server diversi!).

I database noSQL non hanno tutto questo. Se hai bisogno di quella roba, devi farlo da solo, ma se NON ne hai bisogno (e ci sono molte applicazioni che non lo fanno), allora ragazzo, sei fortunato. Il DB non deve eseguire tutte queste complesse operazioni e bloccarsi su gran parte del set di dati, quindi è davvero facile partizionare la cosa su molti server / dischi / qualunque cosa e farlo funzionare molto velocemente.

Non si tratta di NoSQL vs SQL, si tratta di BASE vs ACID.

Lo scalabile deve essere scomposto nei suoi componenti:

• Read ridimensionamento = gestisce volumi più elevati di operazioni di lettura
• Scrittura ridimensionamento = gestisce volumi più elevati di operazioni di scrittura

Database compatibili con ACID (come i tradizionali RDBMS) possono ridimensionare le letture. Non sono intrinsecamente meno efficienti dei database NoSQL perché i (possibili) colli di bottiglia delle prestazioni sono introdotti da cose che NoSQL (a volte) manca (come join e dove restrizioni) che è possibile scegliere di non utilizzare. Gli RDBMS di SQL in cluster possono ridimensionare le letture introducendo nodi aggiuntivi nel cluster. Esistono vincoli per quanto possono essere ridimensionate le operazioni di lettura, ma queste sono imposte dalla difficoltà di aumentare le scritture quando si introducono più nodi nel cluster.

Scrivi il ridimensionamento è dove le cose diventano pelose. Esistono vari vincoli imposti dal principio ACID che non si vedono nelle architetture eventualmente coerenti (BASE):

• Atomicity significa che le transazioni devono essere completate o fallite nel loro insieme, quindi un sacco di contabilità deve essere fatta dietro le quinte per garantire questo.
• I vincoli di coerenza indicano che tutti i nodi nel cluster devono essere identici. Se si scrive su un nodo, questa scrittura deve essere copiata su tutti gli altri nodi prima di restituire una risposta al client. Ciò rende un cluster RDBMS tradizionale difficile da ridimensionare.
• I vincoli di durabilità significano che per non perdere mai una scrittura è necessario assicurarsi che prima che una risposta venga restituita al client, la scrittura sia stata scaricata sul disco.

Per aumentare le operazioni di scrittura o il numero di nodi in un cluster oltre un certo punto, è necessario essere in grado di allentare alcuni dei requisiti ACID:

• La caduta di Atomicity consente di ridurre la durata di blocco delle tabelle (set di dati). Esempio: MongoDB, CouchDB.
• La coerenza di rilascio consente di aumentare le scritture tra i nodi del cluster. Esempi: riak, cassandra.
• La durata di rilascio consente di rispondere ai comandi di scrittura senza scaricare il disco. Esempi: memcache, redis.

I database NoSQL in genere seguono il modello BASE anziché il modello ACID. Abbandonano i requisiti A, C e / o D e in cambio migliorano la scalabilità. Alcuni, come Cassandra, ti consentono di optare per le garanzie ACID quando ne hai bisogno. Tuttavia, non tutti i database NoSQL sono sempre più scalabili.

L'API SQL è priva di un meccanismo per descrivere le query in cui i requisiti di ACID sono attenuati. Questo è il motivo per cui i database BASE sono tutti NoSQL.

Nota personale: un ultimo punto che vorrei sottolineare è che la maggior parte dei casi in cui NoSQL viene attualmente utilizzato per migliorare le prestazioni, sarebbe possibile una soluzione su un RDBMS corretto utilizzando uno schema correttamente normalizzato con indici adeguati. Come dimostrato da questo stesso sito (basato su MS SQL Server), gli RDBMS possono scalare a carichi di lavoro elevati, se li si utilizza in modo appropriato. Le persone che non capiscono come ottimizzare gli RDBMS dovrebbero stare alla larga da NoSQL, perché non comprendono quali rischi stanno correndo con i loro dati.

Aggiornamento (2019-09-17):

Il panorama dei database si è evoluto da quando ho pubblicato questa risposta. Mentre esiste ancora la dicotomia tra il mondo ACID RDBMS e il mondo NoSQL BASE, la linea è diventata più vaga. I database NoSQL hanno aggiunto funzionalità dal mondo RDBMS come l'API SQL e il supporto delle transazioni. Ora ci sono persino database che promettono SQL, ACID e ridimensionamento della scrittura, come Google Cloud Spanner, YugabyteDB o CockroachDB. In genere il diavolo è nei dettagli, ma per la maggior parte questi sono "abbastanza ACIDI". Per un approfondimento sulla tecnologia del database e su come si è evoluta, puoi dare un'occhiata a questo mazzo di diapositive (le note sulle diapositive hanno la spiegazione di accompagnamento).

È vero che i database NoSQL (MongoDB, Redis, Riak, Memcached, ecc.) Non mantengono vincoli di chiave esterna e le operazioni atomiche devono essere specificate in modo più esplicito. È anche vero che i database SQL (SQL Server, Oracle, PostgreSQL, ecc.) Possono essere ridimensionati per gestire requisiti di prestazioni molto elevati da DBA esperti.

I database NoSQL consentono ai programmatori esperti, che sono ben consapevoli delle condizioni di gara e delle operazioni atomiche, di rinunciare a una grande quantità di elaborazione richiesta solo in una piccola percentuale del codice dell'applicazione Web di oggi. I database NoSQL hanno certamente operazioni atomiche e la maggior parte di tutti i requisiti transazionali presenti nei database SQL possono essere ottenuti anche database NoSQL. La differenza è il livello di astrazione. I database NoSQL rimuovono i livelli più alti di astrazione e trasmettono tale capacità al programmatore dell'applicazione, risultando in questo modo un codice più veloce in generale con una maggiore probabilità di corruzione dei dati da parte di programmatori non motivati.

Di conseguenza, è molto più probabile che i database NoSQL vengano utilizzati sempre più pesantemente nello spazio delle applicazioni Web, dove i tempi di sviluppo e le prestazioni sono molto importanti. È probabile che il software finanziario e aziendale mantenga la sua eredità SQL perché le prestazioni dell'hardware sono relativamente economiche, hanno DBA stagionati a portata di mano e l'aumento del rischio causato da programmatori non stagionati non è appetibile.

Da IBM developerWorks: Fornisci scalabilità dei dati a livello di cloud con database NoSQL

La scalabilità è il sistema che dovrebbe essere in grado di supportare database di grandi dimensioni con percentuali di richieste molto elevate a latenza molto bassa.

I sistemi NoSQL hanno in comune una serie di funzionalità di progettazione:

• La capacità di ridimensionare orizzontalmente la velocità effettiva su molti server.
• Una semplice interfaccia o protocollo a livello di chiamata (in contrasto con un'associazione SQL).
• Supporto per modelli di coerenza più deboli rispetto alle transazioni ACID nella maggior parte dei RDBMS tradizionali.
• Uso efficiente di indici distribuiti e RAM per l'archiviazione dei dati.
• La capacità di definire dinamicamente nuovi attributi o schemi di dati.

Perché i database relazionali potrebbero non essere ottimali per il ridimensionamento

In generale, i sistemi di gestione di database relazionali sono stati considerati per decenni "una soluzione unica per la persistenza e il recupero dei dati". Sono maturati dopo numerosi sforzi di ricerca e sviluppo e hanno creato con successo un grande mercato e soluzioni in diversi settori aziendali.

La sempre crescente necessità di scalabilità e nuovi requisiti applicativi hanno creato nuove sfide per RDBMS tradizionale, inclusa una certa insoddisfazione per questo approccio unico per tutte le applicazioni su scala web. La risposta a questo è stata una nuova generazione di software di database a basso costo e ad alte prestazioni progettato per sfidare il dominio dei sistemi di gestione di database relazionali. Un grande motivo del movimento NoSQL è che le diverse implementazioni delle applicazioni di web, enterprise e cloud computing hanno requisiti diversi per i loro database, ad esempio non tutte le applicazioni richiedono una coerenza dei dati rigida.

Un altro esempio: per i siti Web di grandi volumi come eBay, Amazon, Twitter o Facebook, la scalabilità e l'elevata disponibilità sono requisiti essenziali che non possono essere compromessi. Per queste applicazioni, anche la minima interruzione può avere conseguenze finanziarie significative e influire sulla fiducia dei clienti.

Su DBA.SE: cosa significa ridimensionamento orizzontale?

Il ridimensionamento orizzontale si sviluppa essenzialmente anziché su. Non vai a comprare un server più robusto e trasferisci tutto il carico su di esso, invece acquisti 1+ server aggiuntivi e distribuisci il carico su di essi.

Il ridimensionamento orizzontale viene utilizzato quando si ha la possibilità di eseguire più istanze sui server contemporaneamente. In genere è molto più difficile passare da 1 server a 2 server, quindi è da 2 a 5, 10, 50, ecc.

Una volta risolti i problemi legati all'esecuzione di istanze parallele, puoi trarre grande vantaggio da ambienti come Amazon EC2, Rackspace's Cloud Service, GoGrid, ecc. In quanto puoi aumentare e ridurre le istanze in base alla domanda, riducendo la necessità di pagare per l'alimentazione del server non stai usando solo per coprire quei carichi di picco.

I database relazionali sono uno degli elementi più difficili da eseguire in lettura / scrittura completa in parallelo.