Czym różni się NoSQL zorientowany na kolumny od zorientowanego na dokumenty?

Question

Czym różni się NoSQL zorientowany na kolumny od zorientowanego na dokumenty?

Trzy typy baz danych NoSQL, o których czytałem, to key-value, column-oriented I document-oriented.

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

Widziałem zorientowane na dokumenty bazy danych opisane jako jak key-value, ale wartość może być strukturą, jak obiekt JSON. Każdy "dokument" może mieć wszystkie, niektóre lub żaden z tych samych kluczy co inny.

Column oriented wydaje się być bardzo podobne do document oriented, ponieważ nie określa się struktura.

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

Przyjrzałem się Mongodbowi i Cassandrze. Zasadniczo potrzebuję dynamicznej struktury, która może się zmieniać, ale nie wpływać na inne wartości. Jednocześnie muszę być w stanie wyszukiwać/filtrować określone klucze i uruchamiać raporty. W CAP AP jest dla mnie najważniejszy. Dane mogą być" ostatecznie " synchronizowane między węzłami, tak długo, jak nie ma konfliktu lub utraty danych. Każdy użytkownik będzie Zdobądź swój własny "stół".

65

mongodb nosql cassandra

Author: Community, 2011-09-27

Source

3 answers

Główna różnica polega na tym, że magazyny dokumentów (np. MongoDB i CouchDB) pozwalają na arbitralnie złożone dokumenty, np. subdokumenty wewnątrz subdokumentów, listy z dokumentami itp. natomiast magazyny kolumnowe (np. Cassandra i HBase) pozwalają tylko na stały format, np. ścisłe słowniki jednopoziomowe lub dwupoziomowe.

38

Author: Theo,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-28 13:37:20

W "insert", aby używać słów rdbms, bazowanie na dokumentach jest bardziej spójne i proste. Uwaga niż 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 i które zmniejszają dostępność. Na ciężkim systemie zapisu / odczytu, wybierz MongoDB. Rozważ to również, jeśli zawsze planujesz przeczytać całą strukturę obiektu. System oparty na dokumentach jest przeznaczony do zwrotu całego dokumentu, gdy go otrzymasz, i nie jest bardzo silny w zwracam części całego wiersza.

Systemy oparte na kolumnach, takie jak Cassandra, są o wiele lepsze niż systemy oparte na dokumentach w "aktualizacjach". Wartość kolumny można zmieniać nawet bez czytania wiersza, który ją zawiera. Zapis nie musi być wykonywany na tym samym serwerze, wiersz może być zawarty na wielu plikach na wielu serwerach. Na ogromnym, szybko rozwijającym się Systemie danych, idź do Cassandry. Rozważ to również, jeśli planujesz mieć bardzo dużą ilość danych na klucz i nie będziesz musiał ładować ich wszystkich przy każdym zapytaniu. W "Wybierz" Cassandra pozwala załadować tylko potrzebną kolumnę.

Weź również pod uwagę, że Mongo DB jest napisany w C++ i znajduje się w drugim głównym wydaniu, podczas gdy Cassandra musi działać na JVM, a jej pierwsze Główne wydanie jest w Release candidate dopiero od wczoraj (ale 0.X wydania zamieniły się już w produkcje dużej firmy).

[[0]}z drugiej strony, Projekt Cassandry był częściowo oparty na Amazon Dynamo, a jego rdzeń jest zbudowany tak, aby był wysokiej dostępności rozwiązanie, ale to nie ma nic wspólnego z formatem opartym na kolumnach. MongoDB też, ale nie tak wdzięcznie jak Cassandra.

21

Author: user327961,
Warning: date(): Invalid date.timezone value 'Europe/Kyiv', we selected the timezone 'UTC' for now. in /var/www/agent_stack/data/www/doraprojects.net/template/agent.layouts/content.php on line 54
2011-09-28 13:13:47

score 31 · Accepted Answer

W Cassandrze każdy wiersz (adresowany kluczem) zawiera jedną lub więcej "kolumn". Kolumny same są parami klucz-wartość. Nazwy kolumn nie muszą być predefiniowane, tzn. struktura nie jest stała. Kolumny w wierszu są przechowywane w porządku posortowanym według ich kluczy (nazw).

W niektórych przypadkach możesz mieć bardzo dużą liczbę kolumn w wierszu(np. działać jako indeks, aby włączyć określone rodzaje zapytań). Cassandra potrafi sprawnie obsługiwać tak duże konstrukcje, a Ty możesz określone zakresy kolumn.

Istnieje kolejny poziom struktury (nie tak powszechnie stosowany) zwany super-kolumnami, gdzie kolumna zawiera zagnieżdżone (sub)kolumny.

Możesz myśleć o ogólnej strukturze jako zagnieżdżonym hashtable / 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 klawiszy - które mogą być używane do dzielenia lub pogrupować swoje dane.

Zobacz też to pytanie: Cassandra: Co to jest podkolumna

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

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

Wartości kolumn Cassandra są tylko bajtami, ale mogą być wpisywane jako ASCII, tekst 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 magazynu zorientowanego na dokumenty.