Perché NoSQL è migliore per "scalare" rispetto a RDBMS?

Question

Ho letto il seguente testo in un technical blog discutere i vantaggi e gli svantaggi di NoSQL

" Per anni, al fine di migliorare le prestazioni su server di database, gli amministratori di database hanno dovuto acquistare i server più grandi, come il carico del database aumenta (aumentando gradualmente) anziché distribuire il database tra più "host" mentre il carico aumenta (ridimensionamento). Gli RDBMS generalmente non vengono scalati facilmente, ma i nuovi database NoSQL sono effettivamente progettati per espandersi facilmente per sfruttare i nuovi nodi e di solito sono progettati pensando all'hardware delle merci a basso costo "

Sono diventato confuso circa la scalabilità di RDBMS e NoSQL.

La mia confusione sono:

1. Perché RDBMS sono meno in grado di scalare fuori? E la ragione di acquistare server più grandi invece di acquistare quelli più economici.
2. Perché NoSQL è più in grado di scalare?

Answer 1

RDBMS hanno ACID (http://en.wikipedia.org/wiki/ACID) e supporta le transazioni. Scalare "out" con RDBMS è più difficile da implementare a causa di questi concetti.

Le soluzioni NoSQL di solito offrono atomicità a livello di record, ma non possono garantire che una serie di operazioni abbia esito positivo (transazione).

Si tratta di: per mantenere l'integrità dei dati e supportare le transazioni, un RDBMS multi-server dovrebbe disporre di un canale di comunicazione back-end veloce per sincronizzare tutte le transazioni e scritture possibili, impedendo/gestendo il deadlock.

Ecco perché di solito si vedono solo 1 master (scrittore) e più slave (lettori).

Answer 2

I tipici RDBMS sono garanzia di coerenza. Ciò richiede una certa estensione della comunicazione tra i nodi per ogni transazione. Ciò limita la possibilità di ridimensionare, perché più nodi significano più comunicazioni

I sistemi NoSql fanno diversi scambi commerciali. Ad esempio, non garantiscono che una seconda sessione vedrà immediatamente i dati impegnati da una prima sessione. In tal modo disaccoppiamento della transazione di memorizzazione di alcuni dati dal processo di rendere tali dati disponibili per ogni utente. Google "alla fine coerente". Quindi una singola transazione non ha bisogno di attendere alcuna (o molto meno) comunicazione tra i nodi. Pertanto sono in grado di utilizzare una grande quantità di nodi molto più facilmente.

Answer 3

Quindi ho cercato di capire da solo la vera linea di fondo quando si tratta di NoSQL rispetto a RDBMS, e finisco sempre con una risposta che non la abbatte. Nella mia ricerca ci sono davvero 2 differenze primarie tra NoSQL e SQL, con solo 1 come vero vantaggio.

1. ACIDO vs BASE - NoSQL tipicamente lascia fuori alcune delle caratteristiche ACID di SQL, una sorta di 'barare' è modo per prestazioni più elevate, lasciando questo livello di astrazione al programmatore. Questo è già stato coperto da manifesti precedenti.

2. Ridimensionamento orizzontale - Il vero vantaggio di NoSQL è il ridimensionamento orizzontale, ovvero lo sharding.Considerando i 'documenti' di NoSQL si tratta di una sorta di oggetto 'autonomo', gli oggetti possono essere su server diversi senza preoccuparsi di unire le righe da più server, come nel caso del modello relazionale.

Diciamo che vogliamo tornare un oggetto come questo:

post { 
    id: 1 
    title: 'My post' 
    content: 'The content' 
    comments: { 
     comment: { 
     id: 1 
     } 
     comment: { 
     id: 2 
     } 
     ... 

    views: { 
     view: { 
     user: 1 
     } 
     view: { 
     user: 2 
     } 
     ... 
    } 
} 

In NoSQL, quell'oggetto sarebbe praticamente essere conservato così com'è, e quindi può risiedere su un singolo server come una sorta di auto Oggetto con contenuto, senza necessità di collegarsi con i dati di altre tabelle che potrebbero risiedere su altri server DB.

Tuttavia, con i DB relazionali, il post dovrebbe essere associato ai commenti dalla tabella comments e alle viste dalla tabella views. Questo non sarebbe un problema in SQL ~ UNTIL ~ il DB è suddiviso in frammenti, nel qual caso 'commento 1' potrebbe essere su un server DB, mentre 'commento 2' ancora su un altro server DB. Ciò rende molto più difficile creare lo stesso oggetto in un RDBMS che è stato ridimensionato orizzontalmente rispetto a un DB NoSQL.

Eventuali esperti di DB là fuori confermano o discutono questi punti?

Answer 4

Per un NO SQL, 1.Tutto il figlio correlato a una raccolta si trova nello stesso posto e quindi sullo stesso server e non vi è alcuna operazione di unione per cercare i dati da un altro server.

2. Non esiste uno schema, quindi non è necessario alcun blocco su alcun server e la gestione della transazione viene lasciata ai client.

Quanto sopra 2 consente di risparmiare un sacco di spese generali di ridimensionamento in NO-SQL.