Czym różni się język NoSQL zorientowany na kolumny od zorientowanego na dokument?

Trzy typy baz danych NoSQL, o których czytałem, to klucz-wartość, zorientowana na kolumny i zorientowana na dokument.

Klucz-wartość jest dość prosty - klucz o zwykłej wartości.

Widziałem bazy danych zorientowane na dokumenty opisane jako klucz-wartość, ale wartością może być struktura, taka jak obiekt JSON. Każdy „dokument” może mieć wszystkie, niektóre lub żaden z tych samych kluczy.

Zorientowany na kolumny wydaje się być bardzo podobny do zorientowanego na dokument, ponieważ nie określa się struktury.

Jaka jest więc różnica między tymi dwoma i dlaczego miałbyś używać jednego nad drugim?

Specjalnie przyjrzałem się MongoDB i Cassandrze. Zasadniczo potrzebuję dynamicznej struktury, która może się zmieniać, ale nie wpływa na inne wartości. Jednocześnie muszę mieć możliwość wyszukiwania / filtrowania określonych kluczy i generowania raportów. W przypadku CAP najważniejsze jest dla mnie AP. Dane można „ostatecznie” zsynchronizować między węzłami, o ile nie występuje konflikt lub utrata danych. Każdy użytkownik otrzyma własną „tabelę”.

W Cassandrze każdy wiersz (zaadresowany przez klucz) zawiera jedną lub więcej „kolumn”. Kolumny same w sobie są parami klucz-wartość. Nazwy kolumn nie muszą być predefiniowane, tj. Struktura nie jest ustalona. Kolumny w wierszu są przechowywane w kolejności posortowanej według kluczy (nazw).

W niektórych przypadkach możesz mieć bardzo dużą liczbę kolumn w wierszu (np. Pełnić rolę indeksu umożliwiającego określone rodzaje zapytań). Cassandra radzi sobie skutecznie z tak dużymi strukturami, a Ty możesz pobierać określone zakresy kolumn.

Istnieje kolejny poziom struktury (niezbyt często używany) zwany superkolumnami, gdzie kolumna zawiera zagnieżdżone (pod) kolumny.

Możesz myśleć o ogólnej strukturze jako o zagnieżdżonej tablicy hashy / słowniku z 2 lub 3 poziomami klucza.

Normalna rodzina kolumn:

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

Rodzina super kolumn:

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

Istnieją również struktury wyższego poziomu - rodziny kolumn i przestrzenie kluczowe - których można używać do dzielenia lub grupowania danych.

Zobacz także to pytanie: Cassandra: Co to jest kolumna podrzędna

Lub linki do modelowania danych z http://wiki.apache.org/cassandra/ArticlesAndPresentations

Re: porównanie z bazami danych zorientowanymi na dokumenty - te ostatnie zazwyczaj wstawiają całe dokumenty (zwykle JSON), podczas gdy w Cassandrze można adresować poszczególne kolumny lub superkolumny i aktualizować je indywidualnie, czyli działają na innym poziomie szczegółowości. Każda kolumna ma swój oddzielny znacznik czasu / wersję (używany do uzgadniania aktualizacji w rozproszonym klastrze).

Wartości kolumny Cassandra to tylko bajty, ale można je wpisać jako tekst ASCII, UTF8, liczby, daty itp.

Oczywiście możesz użyć Cassandry jako prymitywnego magazynu dokumentów, wstawiając kolumny zawierające JSON - ale nie uzyskasz wszystkich funkcji prawdziwego sklepu zorientowanego na dokumenty.

Główna różnica polega na tym, że magazyny dokumentów (np. MongoDB i CouchDB) pozwalają na dowolnie złożone dokumenty, tj. Dokumenty podrzędne w ramach dokumentów podrzędnych, listy z dokumentami itp., Podczas gdy magazyny kolumnowe (np. Cassandra i HBase) dopuszczają tylko stały format, np. Ścisły jednopoziomowy lub słowniki dwupoziomowe.

W przypadku „wstawiania”, aby użyć słów rdbms, Oparty na dokumencie jest bardziej spójny i bezpośredni. Uwaga, Cassandra pozwala osiągnąć spójność z pojęciem kworum, ale nie będzie to miało zastosowania do wszystkich systemów opartych na kolumnach, a to zmniejsza dostępność. W systemie z częstym zapisem / częstym odczytem wybierz MongoDB. Weź to również pod uwagę, jeśli zawsze planujesz przeczytać całą strukturę obiektu. System oparty na dokumentach jest przeznaczony do zwracania całego dokumentu po jego otrzymaniu i nie jest zbyt silny w zwracaniu części całego wiersza.

Systemy oparte na kolumnach, takie jak Cassandra, są o wiele lepsze niż oparte na dokumentach w „aktualizacjach”. Możesz zmienić wartość kolumny bez czytania wiersza, który ją zawiera. Zapis nie musi być faktycznie wykonywany na tym samym serwerze, wiersz może znajdować się w wielu plikach na wielu serwerach. W ogromnym, szybko rozwijającym się systemie danych wybierz Cassandrę. Weź to również pod uwagę, jeśli planujesz mieć bardzo dużą porcję danych na klucz i nie musisz ładować ich wszystkich przy każdym zapytaniu. W opcji „wybierz” Cassandra pozwala załadować tylko potrzebną kolumnę.

Weź również pod uwagę, że Mongo DB jest napisane w C ++ i jest drugim głównym wydaniem, podczas gdy Cassandra musi działać na JVM, a jego pierwsze główne wydanie jest kandydatem do wydania dopiero od wczoraj (ale wydania 0.X obróciły się w produkcje duża firma).

Z drugiej strony, Cassandra zaprojektowana była częściowo w oparciu o Amazon Dynamo i jest zbudowana w swej istocie jako rozwiązanie o wysokiej dostępności, ale nie ma to nic wspólnego z formatem opartym na kolumnach. MongoDB również się skaluje, ale nie tak wdzięcznie jak Cassandra.

Powiedziałbym, że główną różnicą jest sposób fizycznego przechowywania danych przez każdy z tych typów baz danych.
W przypadku typów kolumn dane są przechowywane w kolumnach, co może umożliwić wydajne operacje agregacji / zapytania w określonej kolumnie.
W przypadku typów dokumentów cały dokument jest logicznie przechowywany w jednym miejscu i generalnie pobierany jako całość (brak możliwości wydajnej agregacji w „kolumnach” / „polach”).

Mylące jest to, że „wiersz” z szerokimi kolumnami można łatwo przedstawić jako dokument, ale, jak wspomniano, są one przechowywane w inny sposób i zoptymalizowane do różnych celów.