Recentemente ho letto molto sui DBMS noSQL. Comprendo il teorema CAP , ACID regole, regole BASE e teoria di base. Ma non ha 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 i vincoli e le chiavi esterne costino risorse e quando un DBMS è distribuito, è molto più complicato. Ma mi aspetto che ci sia molto più di questo.
Qualcuno può spiegare come noSQL / SQL influenza la scalabilità?
I database noSQL offrono una grande quantità di funzionalità che un database SQL ti dà in base alla sua natura.
Cose come l'applicazione automatica dell'integrità referenziale, delle transazioni, ecc. Queste sono tutte cose che sono molto utili per alcuni problemi e che richiedono alcune tecniche interessanti per scalare all'esterno di un singolo server (pensa a cosa succede se ti serve bloccare due tabelle per una transazione atomica e sono su server diversi!).
i database noSQL non hanno tutto questo. Se hai bisogno di quella roba, devi farlo da te, ma se non ne hai bisogno (e ci sono un sacco di applicazioni che non lo fanno), allora ragazzo sei fortunato. Il DB non deve fare tutte queste operazioni complesse e bloccare su gran parte del set di dati, quindi è molto semplice suddividere la cosa su molti server / dischi / qualsiasi altra cosa e farlo funzionare molto velocemente.
Non si tratta di NoSQL vs SQL, si tratta di BASE vs ACID.
Scalabile deve essere suddiviso nei suoi componenti:
I database compatibili con ACID (come gli RDBMS tradizionali) possono ridimensionare le letture. Non sono intrinsecamente meno efficienti dei database NoSQL perché i (possibili) colli di bottiglia delle prestazioni sono introdotti da cose a cui NoSQL (a volte) manca (come i join e le restrizioni) che è possibile scegliere di non utilizzare. Gli RDBMS SQL raggruppati possono ridimensionare le letture introducendo nodi aggiuntivi nel cluster. Ci sono dei vincoli su quanto possono essere ridimensionate le operazioni di lettura, ma queste sono imposte dalla difficoltà di ridimensionare le scritture quando si introducono più nodi nel cluster.
Scrivere il ridimensionamento è dove le cose si fanno pelose. Vi sono vari vincoli imposti dal principio ACID che non si vedono in architetture alla fine coerenti (BASE):
Per aumentare le operazioni di scrittura o il numero di nodi in un cluster oltre un certo punto devi essere in grado di rilassare alcuni dei requisiti ACID:
I database NoSQL in genere seguono il modello BASE anziché il modello ACID. Rinunciano ai requisiti A, C e / o D e, in cambio, migliorano la scalabilità. Alcuni, come Cassandra, ti consentono di attivare le garanzie ACID quando ne hai bisogno. Tuttavia, non tutti i database NoSQL sono sempre più scalabili.
L'API SQL non ha un meccanismo per descrivere le query in cui i requisiti di ACID sono rilassati. Questo è il motivo per cui i database BASE sono tutti NoSQL.
Nota personale: un ultimo punto che vorrei fare è che la maggior parte dei casi in cui NoSQL è attualmente utilizzato per migliorare le prestazioni, una soluzione sarebbe possibile su un RDBMS appropriato utilizzando uno schema correttamente normalizzato con indici appropriati. Come dimostrato da questo stesso sito (basato su MS SQL Server), gli RDBMS possono scalare carichi di lavoro elevati, se li si utilizza in modo appropriato. Le persone che non capiscono come ottimizzare RDBMS dovrebbero stare lontano da NoSQL, perché non capiscono quali rischi stanno prendendo con i loro dati.
Da IBM developerWorks: Fornire scalabilità dei dati a livello di cloud con NoSQL database
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 numerose funzionalità di progettazione:
Perché i database relazionali potrebbero non essere ottimali per il ridimensionamento
In generale, i sistemi di gestione dei database relazionali sono stati considerati per decenni una "soluzione unica per la persistenza e il recupero dei dati". Sono maturati dopo intensi 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 gli RDBMS tradizionali, tra cui alcuni insoddisfatti di questo approccio one-size-fits-all in alcune applicazioni su scala web. La risposta a questa è stata una nuova generazione di software di database a basso costo e ad alte prestazioni progettato per sfidare il dominio dei sistemi di gestione dei database relazionali. Una delle ragioni principali del movimento NoSQL è che le diverse implementazioni di applicazioni web, enterprise e di cloud computing hanno requisiti diversi dei loro database - non tutte le applicazioni richiedono una rigida coerenza dei dati, ad esempio.
Un altro esempio: per i siti Web di volume elevato come eBay, Amazon, Twitter o Facebook, la scalabilità e l'alta 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.
Over su DBA.SE: Che cosa significa ridimensionamento orizzontale?
Il ridimensionamento orizzontale si basa essenzialmente sulla costruzione anziché su. Non vai a comprare un server più grande e più carico e sposta tutto il carico su di esso, invece acquisti 1+ server aggiuntivi e li distribuisci su di loro.
Il ridimensionamento orizzontale viene utilizzato quando è possibile eseguire più istanze sui server contemporaneamente. In genere è molto più difficile passare da 1 server a 2 server, quindi passare da 2 a 5, 10, 50, ecc.
Una volta affrontati i problemi relativi 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 la potenza del server che non stai usando solo per coprire quei carichi di punta.
I database relazionali sono uno degli elementi più difficili da eseguire in lettura / scrittura completa in parallelo.
È 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 parte di DBA stagionati.
I database NoSQL consentono ai programmatori esperti, che conoscono bene le condizioni di gara e le 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 dei requisiti transazionali presenti nei database SQL può anche essere ottenuta con i database NoSQL. La differenza è il livello di astrazione. I database NoSQL rimuovono i livelli più alti di astrazione e passano tale funzionalità al programmatore dell'applicazione, risultando quindi un codice più veloce in generale con l'aumento della probabilità di danneggiamento dei dati da parte di programmatori non stagionati.
Di conseguenza, è molto più probabile che i database NoSQL vengano utilizzati sempre più pesantemente nello spazio delle applicazioni Web, dove i tempi e le prestazioni di sviluppo 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 e il rischio aumentato causato dai programmatori non stagionati non è accettabile.
Leggi altre domande sui tag sql nosql scalability