8

Comprendo che i DB NoSQL orientati ai documenti sono "estensioni" del modello KV in quanto consentono di eseguire query su più di una singola chiave di ricerca. Ma una volta che qualcosa è un "documento", mi sento come ha già un modello relazionale cotto in esso:Relazionale vs Database colonnare e Documento - non sono uno nello stesso?

"myJson": { 
    "fizz": 4, 
    "buzz": "true", 
    "widget" : { 
     ...etc. 
    } 
} 

Per me, non vedo la differenza tra questo JSON, e un tavolo con un json_objectsfizz e il campo buzz e una relazione di chiave esterna con una seconda tabella widgets.

E i DB "a colonne" come Cassandra sembrano solo DB relazionali/di tabella.

Quindi, mi chiedo: cosa c'è di così diverso nei DB basati su documenti e colonne e quindi distinguere (da RDBMS) su di essi? Quali problemi sono più adatti a risolvere che li rendono superiori ai DB relazionali in determinate circostanze? Grazie in anticipo!

risposta

17

In primo luogo, vorrei dire che lei ha ragione nel dire che NoSql è diverso dai database relazionali e quindi è difficile fare un confronto. Con quello detto ci sono molte grandi distinzioni tra le due che possono essere confrontate.

Scaling
Anche se è possibile coccio un database MySql ci sono issues con sharding e enforcing ACID properties quando un RDMS è su più macchine sarà molto impegnativo, soluzioni NoSQL come Cassandra sono famosi per la loro capacità di crescere senza problemi con alcuni casi che gestiscono 400 nodes in a cluster senza problemi. Non solo è facile far crescere un database Cassandra, ma le prestazioni non sono un successo.

Schema (in meno) modello.
I sistemi di database NoSQL sono sviluppati per gestire grandi volumi di dati che non seguono uno schema fisso. Questo significa che ad esempio si desidera aggiungere una nuova colonna ad una famiglia colonna esistente in Cassandra non è necessario tornare indietro e modificare la famiglia di pilastri così non c'è bisogno di questo:

ALTER TABLE table_name ALTER COLUMN column_name datatype; 

Possiamo invece basta aggiungere nuove colonne come andiamo, e potrebbero finire con il seguente 'tabella':

key   | follower1 | follower2 | follower2   
-------------+------------+-------------+----------- 
lyubent  | joeb  | chuckn  | gordonf  
chuckn  | joeb  | gordonf     
gordonf  | chuckn         
joeb  | chuckn  | lyubent  | joeb   

Questo permette modelli di dati per essere flessibile e facilmente esteso ma in questo modo i dati diventa meno strutturati.

Velocità database NoSQL
sono ottimizzati per high write speeds mentre scopo RDBMS' per elevate velocità di lettura. Ma anche con questo in mente le soluzioni NoSql tendono ancora a sistemi outperform RDBMs quando si tratta di letture. Questo perché i database NoSql non implementano molte delle funzioni che rallentano le operazioni di lettura/scrittura/aggiornamento nel modello relazionale come ad esempio le proprietà e le transazioni ACID.

When should it be used?

  • La vostra applicazione/sito web dovrà crescere rapidamente ma si desidera iniziare in piccolo.
  • Sei più interessato a scrivere i dati che a leggerli di nuovo.(Vengono inviati molti tweet ma non tutti vengono letti)
  • La disponibilità del sistema è più importante del fatto che i dati vengano aggiornati al 100%. (Quindi se sei una banca, non vuoi NoSql ma se sei un sito web che richiede il 100% di uptime potrebbe essere una buona scelta)
  • Se i dati scritti devono avere successo al 100% del tempo, ma la consistenza finale non è un problema.

Solo per una illustrazione visiva, questo mi ha aiutato molto a capire dove le diverse soluzioni sql si adattano al mondo del database e come ognuna si adatta a uno scopo.

Database Triad - Availability, Consistency and Partition Tolerance

+1

Questo diagramma è completamente errato, non è possibile avere CA db. Non può avere A se non è tollerante alle partizioni. Quel diagramma è stato fatto da qualcuno che ha frainteso il teorema della PAC. Non è possibile scegliere 2, è necessario scegliere tra C o A. http://codahale.com/you-cant-sacrifice-partition-tolerance Tale collegamento è stato twittato da Brewer (autore del teorema CAP). Pensaci, quale proprietà CAP distribuisce MySql (sharded (che HBase non ha? Mostrami uno scenario in cui MySql ha disponibilità e HBase no. – user1944408

+0

I sistemi RDBMS garantiscono coerenza e sharding rendono il sistema tollerante al partizionamento. il teorema fa sì che il sistema non possa garantire la disponibilità, quindi i sistemi RDBMS sono CP. – user1944408

+7

@ user1944408 La critica è sempre apprezzata, tuttavia si dice che il diagramma è completamente errato a causa del punto in cui HBase e MySql si trovano sul diagramma. l'immagine è stata utilizzata in un certo numero di [risposte] (http://stackoverflow.com/questions/2794736/best-data-store-for-billions-of-rows#answer-2794983) di SO e per favore avere una lettura [questo articolo] (http://blog.nahurst.com/visual-guide-to-nosql-systems) che giustifica il motivo per cui MySql è stato inserito come CA, o se non si desidera ... sono lì per un confronto, è una guida ai database NoSql, non ai RDBM ' . –

2

In nessun schema db non si dispone di colonne fisse e tipi.

Ad esempio, il prodotto "Jeans" può avere attributi "prezzo", "lunghezza" e "modello" (M/W) ma per il libro del prodotto si hanno attributi "prezzo", "autori" e "titolo". Per i telefoni cellulari avrai "tipo di schermo", "sistema operativo" ecc.

È molto difficile modellarlo in RDBMS perché non sei flessibile e l'utente non può inserire attributi arbitrari quindi è più facile usare un database di documenti che sono ottimizzati per questo tipo di dati in modo da poter facilmente cercare e filtrare per valore su attributi arbitrari (ad esempio tutti i prodotti con lunghezza> 30 e modello = w).