Wie unterscheidet sich spaltenorientiertes NoSQL von dokumentenorientiertem?

Die drei Arten von NoSQL-Datenbanken, über die ich gelesen habe, sind Schlüsselwert-, Spalten- und Dokumentorientierung.

Der Schlüsselwert ist ziemlich einfach - ein Schlüssel mit einem einfachen Wert.

Ich habe dokumentenorientierte Datenbanken gesehen, die als Schlüsselwert beschrieben wurden, aber der Wert kann eine Struktur sein, wie ein JSON-Objekt. Jedes "Dokument" kann alle, einige oder keine der gleichen Schlüssel wie ein anderes haben.

Spaltenorientiert scheint Dokumentorientiert zu sein, da Sie keine Struktur angeben.

Was ist der Unterschied zwischen diesen beiden und warum sollten Sie einen über den anderen verwenden?

Ich habe mir MongoDB und Cassandra speziell angesehen. Ich brauche grundsätzlich eine dynamische Struktur, die sich ändern kann, aber andere Werte nicht beeinflusst. Gleichzeitig muss ich in der Lage sein, bestimmte Schlüssel zu suchen / zu filtern und Berichte auszuführen. Bei CAP ist AP für mich das Wichtigste. Die Daten können "eventuell" knotenübergreifend synchronisiert werden, solange kein Konflikt oder Datenverlust vorliegt. Jeder Benutzer würde seine eigene "Tabelle" bekommen.

In Cassandra enthält jede Zeile (mit einem Schlüssel adressiert) eine oder mehrere "Spalten". Spalten sind selbst Schlüssel-Wert-Paare. Die Spaltennamen müssen nicht vordefiniert sein, dh die Struktur ist nicht festgelegt. Spalten in einer Zeile werden in sortierter Reihenfolge nach ihren Schlüsseln (Namen) gespeichert.

In einigen Fällen haben Sie möglicherweise eine sehr große Anzahl von Spalten in einer Zeile (z. B. als Index, um bestimmte Arten von Abfragen zu aktivieren). Cassandra kann so große Strukturen effizient handhaben, und Sie können bestimmte Spaltenbereiche abrufen.

Es gibt eine weitere Strukturebene (nicht so häufig verwendet), die als Superspalten bezeichnet wird, wobei eine Spalte verschachtelte (Unter-) Spalten enthält.

Sie können sich die Gesamtstruktur als verschachtelte Hashtabelle / Wörterbuch mit 2 oder 3 Schlüsselebenen vorstellen.

Normale Spaltenfamilie:

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

Supersäulenfamilie:

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

Es gibt auch übergeordnete Strukturen - Spaltenfamilien und Schlüsselbereiche -, mit denen Sie Ihre Daten aufteilen oder gruppieren können.

Siehe auch diese Frage: Cassandra: Was ist eine Unterspalte?

Oder die Datenmodellierungslinks von http://wiki.apache.org/cassandra/ArticlesAndPresentations

Betreff: Vergleich mit dokumentenorientierten Datenbanken - letztere fügen normalerweise ganze Dokumente (normalerweise JSON) ein, während Sie in Cassandra einzelne Spalten oder Superspalten adressieren und einzeln aktualisieren können, dh sie arbeiten auf einer anderen Granularitätsstufe. Jede Spalte verfügt über einen eigenen Zeitstempel / eine eigene Version (zum Abgleichen von Aktualisierungen im verteilten Cluster).

Die Cassandra-Spaltenwerte sind nur Bytes, können jedoch als ASCII-, UTF8-Text, Zahlen, Datumsangaben usw. eingegeben werden.

Natürlich könnten Sie Cassandra als primitiven Dokumentenspeicher verwenden, indem Sie Spalten einfügen, die JSON enthalten - aber Sie würden nicht alle Funktionen eines echten dokumentenorientierten Speichers erhalten.

Der Hauptunterschied besteht darin, dass Dokumentenspeicher (z. B. MongoDB und CouchDB) beliebig komplexe Dokumente zulassen, dh Unterdokumente innerhalb von Unterdokumenten, Listen mit Dokumenten usw., während Spaltenspeicher (z. B. Cassandra und HBase) nur ein festes Format zulassen, z. B. strikte einstufige oder zweistufige Wörterbücher.

In "Einfügen" ist "Dokumentbasiert" konsistenter und direkter, um rdbms-Wörter zu verwenden. Beachten Sie, dass Sie mit Cassandra eine Übereinstimmung mit dem Begriff des Quorums erzielen können. Dies gilt jedoch nicht für alle spaltenbasierten Systeme und verringert die Verfügbarkeit. Entscheiden Sie sich auf einem System mit einmaligem Schreiben und häufigem Lesen für MongoDB. Berücksichtigen Sie dies auch, wenn Sie immer die gesamte Struktur des Objekts lesen möchten. Ein dokumentbasiertes System ist so konzipiert, dass es das gesamte Dokument zurückgibt, wenn Sie es erhalten, und ist nicht sehr stark darin, Teile der gesamten Zeile zurückzugeben.

Die spaltenbasierten Systeme wie Cassandra sind in "Updates" weitaus besser als dokumentbasierte. Sie können den Wert einer Spalte ändern, ohne die Zeile zu lesen, die sie enthält. Der Schreibvorgang muss nicht unbedingt auf demselben Server ausgeführt werden. Eine Zeile kann in mehreren Dateien mehrerer Server enthalten sein. Entscheiden Sie sich auf einem riesigen, sich schnell entwickelnden Datensystem für Cassandra. Berücksichtigen Sie dies auch, wenn Sie einen sehr großen Datenblock pro Schlüssel planen und nicht alle bei jeder Abfrage laden müssen. In "Auswählen" können Sie mit Cassandra nur die Spalte laden, die Sie benötigen.

Bedenken Sie auch, dass Mongo DB in C ++ geschrieben ist und sich in der zweiten Hauptversion befindet, während Cassandra auf einer JVM ausgeführt werden muss und die erste Hauptversion erst seit gestern im Release Candidate ist (aber die 0.X-Versionen wurden in Produktionen von gedreht großes Unternehmen bereits).

Auf der anderen Seite basierte Cassandras Design teilweise auf Amazon Dynamo und ist im Kern als Hochverfügbarkeitslösung konzipiert, was jedoch nichts mit dem spaltenbasierten Format zu tun hat. MongoDB skaliert ebenfalls, aber nicht so anmutig wie Cassandra.

Ich würde sagen, dass der Hauptunterschied darin besteht, wie jeder dieser DB-Typen die Daten physisch speichert.
Bei Spaltentypen werden die Daten in Spalten gespeichert, die effiziente Aggregationsoperationen / Abfragen für eine bestimmte Spalte ermöglichen.
Bei Dokumenttypen wird das gesamte Dokument logisch an einem Ort gespeichert und im Allgemeinen als Ganzes abgerufen (keine effiziente Aggregation für "Spalten" / "Felder" möglich).

Das verwirrende Bit ist, dass eine breitspaltige "Zeile" leicht als Dokument dargestellt werden kann, aber wie erwähnt unterschiedlich gespeichert und für unterschiedliche Zwecke optimiert wird.