In che modo NoSQL orientato alle colonne differisce da NoSQL orientato ai documenti?

I tre tipi di database NoSQL di cui ho letto sono valori-chiave, orientati alle colonne e orientati ai documenti.

Il valore-chiave è piuttosto semplice: una chiave con un valore semplice.

Ho visto database orientati ai documenti descritti come come valori-chiave, ma il valore può essere una struttura, come un oggetto JSON. Ogni "documento" può avere tutte, alcune o nessuna delle stesse chiavi di un altro.

L'orientamento a colonne sembra essere molto simile all'orientamento a documenti in quanto non si specifica una struttura.

Allora qual è la differenza tra questi due e perché dovresti usarne uno sull'altro?

Ho esaminato specificamente MongoDB e Cassandra. Fondamentalmente ho bisogno di una struttura dinamica che possa cambiare, ma non influire su altri valori. Allo stesso tempo, devo essere in grado di cercare / filtrare chiavi specifiche ed eseguire rapporti. Con CAP, l'AP è il più importante per me. I dati possono "eventualmente" essere sincronizzati tra i nodi, purché non vi siano conflitti o perdite di dati. Ogni utente otterrebbe la propria "tabella".

In Cassandra, ogni riga (indirizzata da una chiave) contiene una o più "colonne". Le colonne sono esse stesse coppie chiave-valore. I nomi delle colonne non devono essere predefiniti, ovvero la struttura non è fissa. Le colonne di una riga vengono memorizzate in ordine ordinato in base alle rispettive chiavi (nomi).

In alcuni casi, potresti avere un numero molto elevato di colonne in una riga (ad esempio per agire come un indice per abilitare particolari tipi di query). Cassandra è in grado di gestire strutture così grandi in modo efficiente e puoi recuperare intervalli specifici di colonne.

Esiste un ulteriore livello di struttura (non così comunemente usato) chiamato supercolonne, in cui una colonna contiene colonne nidificate (sotto).

Puoi pensare alla struttura complessiva come a una tabella hash / dizionario annidata, con 2 o 3 livelli di chiave.

Famiglia di colonne normali:

row
    col  col  col ...
    val  val  val ...

Famiglia di super colonne:

row
      supercol                      supercol                     ...
          (sub)col  (sub)col  ...       (sub)col  (sub)col  ...
           val       val      ...        val       val      ...

Esistono anche strutture di livello superiore - famiglie di colonne e spazi delle chiavi - che possono essere utilizzate per suddividere o raggruppare i dati.

Vedi anche questa Domanda: Cassandra: Cos'è una sottocolonna

O i collegamenti alla modellazione dei dati da http://wiki.apache.org/cassandra/ArticlesAndPresentations

Oggetto: confronto con database document-oriented - questi ultimi solitamente inseriscono documenti interi (tipicamente JSON), mentre in Cassandra puoi indirizzare singole colonne o supercolonne, e aggiornarle singolarmente, cioè funzionano a un diverso livello di granularità. Ogni colonna ha il proprio timestamp / versione separato (utilizzato per riconciliare gli aggiornamenti nel cluster distribuito).

I valori della colonna Cassandra sono solo byte, ma possono essere digitati come ASCII, testo UTF8, numeri, date ecc.

Ovviamente, potresti usare Cassandra come archivio di documenti primitivo inserendo colonne contenenti JSON, ma non otterrai tutte le funzionalità di un vero archivio orientato ai documenti.

La differenza principale è che gli archivi di documenti (ad esempio MongoDB e CouchDB) consentono documenti arbitrariamente complessi, ad esempio documenti secondari all'interno di documenti secondari, elenchi con documenti, ecc. Mentre gli archivi di colonne (ad esempio Cassandra e HBase) consentono solo un formato fisso, ad esempio rigoroso a un livello o dizionari a due livelli.

In "insert", per usare le parole rdbms, Document-based è più coerente e diretto. Nota che cassandra ti consente di ottenere coerenza con la nozione di quorum, ma ciò non si applica a tutti i sistemi basati su colonne e ciò riduce la disponibilità. Su un sistema pesante di scrittura una volta / lettura spesso, scegli MongoDB. Consideralo anche se prevedi di leggere sempre l'intera struttura dell'oggetto. Un sistema basato su documenti è progettato per restituire l'intero documento quando lo si riceve e non è molto efficace nel restituire parti dell'intera riga.

I sistemi basati su colonne come Cassandra sono molto migliori degli "aggiornamenti" basati su documenti. Puoi modificare il valore di una colonna senza nemmeno leggere la riga che la contiene. La scrittura in realtà non deve essere eseguita sullo stesso server, una riga può essere contenuta su più file di più server. Su un enorme sistema di dati in rapida evoluzione, scegli Cassandra. Consideralo anche se prevedi di avere una grande quantità di dati per chiave e non è necessario caricarli tutti a ogni query. In "seleziona", Cassandra ti permette di caricare solo la colonna che ti serve.

Considera anche che Mongo DB è scritto in C ++, ed è alla sua seconda major release, mentre Cassandra ha bisogno di girare su una JVM, e la sua prima major release è in release candidate solo da ieri (ma le versioni 0.X si sono trasformate in produzioni di grande azienda già).

D'altra parte, il design di Cassandra era in parte basato su Amazon Dynamo ed è costruito al suo interno per essere una soluzione ad alta disponibilità, ma questo non ha nulla a che fare con il formato basato su colonne. Anche MongoDB si ridimensiona, ma non con la grazia di Cassandra.

Direi che la differenza principale è il modo in cui ciascuno di questi tipi di database memorizza fisicamente i dati.
Con i tipi di colonna, i dati vengono archiviati in colonne che possono consentire operazioni / query di aggregazione efficienti su una particolare colonna.
Con i tipi di documento, l'intero documento viene memorizzato logicamente in un unico luogo e generalmente viene recuperato nel suo insieme (nessuna aggregazione efficiente possibile su "colonne" / "campi").

La parte che crea confusione è che una "riga" di colonne larghe può essere facilmente rappresentata come un documento, ma, come detto, vengono memorizzate in modo diverso e ottimizzate per scopi diversi.