Чим орієнтований на стовпці NoSQL відрізняється від документ-орієнтованого?

Три типи баз даних NoSQL, про які я читав, це ключ-значення, орієнтований на стовпці та документ.

Ключ-значення досить прямий - ключ із простим значенням.

Я бачив орієнтовані на документи бази даних, що описуються як ключ-значення, але значення може бути структурою, як об'єкт JSON. Кожен "документ" може мати всі, деякі або жоден з тих самих ключів, що й інший.

Орієнтований на стовпці схожий на документ, орієнтований на те, що ви не вказуєте структуру.

То яка різниця між цими двома, і чому б ви використовували одне над іншим?

Я спеціально розглядав MongoDB та Cassandra. Мені в основному потрібна динамічна структура, яка може змінюватися, але не впливати на інші значення. Одночасно мені потрібно мати можливість шукати / фільтрувати певні клавіші та запускати звіти. Для CAP AP є для мене найважливішим. Дані можуть "врешті-решт" синхронізуватися між вузлами, лише якщо немає конфлікту чи втрати даних. Кожен користувач отримав би свою "таблицю".

У Кассандрі кожен рядок (до якого звертається ключ) містить один або кілька "стовпців". Стовпці самі по собі є парами ключ-значення. Назви стовпців не потрібно задавати заздалегідь, тобто структура не є фіксованою. Стовпці в рядку зберігаються у відсортованому порядку відповідно до їх ключів (імен).

У деяких випадках у вас може бути дуже велика кількість стовпців підряд (наприклад, щоб діяти як індекс, щоб увімкнути певні типи запитів). Кассандра може ефективно обробляти такі великі структури, і ви можете отримувати певні діапазони колон.

Існує ще один рівень структури (не так часто вживаний), який називається супер-стовпцями, де стовпець містить вкладені (допоміжні) стовпці.

Ви можете уявити загальну структуру як вкладений хеш-таблицю / словник з 2 або 3 рівнями ключа.

Звичайне сімейство стовпців:

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

Супер сімейство колонок:

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

Існують також структури вищого рівня - сімейства стовпців і простори ключів, - які можна використовувати для розподілу або групування даних.

Дивіться також це запитання: Кассандра: Що таке підколонка

Або посилання на моделювання даних з http://wiki.apache.org/cassandra/ArticlesAndPresentations

Щодо: порівняння з орієнтованими на документи базами даних - останні зазвичай вставляють цілі документи (як правило, JSON), тоді як у Кассандрі ви можете звертатися до окремих стовпців або суперколонок та оновлювати їх окремо, тобто вони працюють на різному рівні деталізації. Кожен стовпець має свою окрему позначку часу / версію (використовується для узгодження оновлень у розподіленому кластері).

Значення стовпця Кассандри - це просто байти, але їх можна ввести як ASCII, текст UTF8, числа, дати тощо.

Звичайно, ви можете використовувати Кассандру як примітивний сховище документів, вставляючи стовпці, що містять JSON - але ви не отримаєте всіх можливостей справжнього сховища, орієнтованого на документи.

Основна відмінність полягає в тому, що сховища документів (наприклад, MongoDB та CouchDB) дозволяють довільно складні документи, тобто піддокументи в піддокументах, списки з документами тощо, тоді як сховища стовпців (наприклад, Cassandra та HBase) дозволяють лише фіксований формат, наприклад, строгий однорівневий або дворівневі словники.

У "вставці", щоб використовувати слова rdbms, Документознавство є більш послідовним і прямим вперед. Примітка, ніж cassandra, дозволяє вам досягти узгодженості з поняттям кворуму, але це не стосуватиметься всіх систем на основі стовпців і що зменшує доступність. На важкій системі, що пише один раз / часто читає, перейдіть до MongoDB. Також враховуйте це, якщо ви завжди плануєте прочитати всю структуру об’єкта. Система, заснована на документах, призначена для повернення цілого документа, коли ви його отримаєте, і не дуже сильна при поверненні частин цілого рядка.

Системи, що базуються на стовпцях, такі як Кассандра, набагато кращі за документи, орієнтовані на "оновлення". Ви можете змінити значення стовпця, навіть не прочитавши рядок, який його містить. Запис фактично не потрібно робити на одному сервері, рядок може міститися в декількох файлах декількох серверів. На величезній швидкозростаючій системі даних вирушайте до Кассандри. Також розгляньте це, якщо ви плануєте мати дуже великий шматок даних на ключ, і вам не потрібно буде завантажувати їх усі під час кожного запиту. У "вибрати" Cassandra дозволяє завантажувати лише потрібний стовпець.

Також врахуйте, що Mongo DB написана на C ++ і перебуває у другому великому випуску, тоді як Кассандрі потрібно працювати на JVM, а її перший великий випуск є кандидатом на випуск лише з вчора (але випуски 0.X перетворилися на виробництва вже велика компанія).

З іншого боку, розроблений Кассандрою частково базувався на Amazon Dynamo, і в основі його побудовано як рішення високої доступності, але це не має нічого спільного з форматом на основі стовпців. MongoDB теж масштабується, але не настільки витончено, як Кассандра.

Я б сказав, що основна відмінність полягає в тому, як кожен із цих типів БД фізично зберігає дані.
Для типів стовпців дані зберігаються стовпцями, що може забезпечити ефективні операції / запити агрегування для конкретного стовпця.
З типами документів весь документ логічно зберігається в одному місці і, як правило, отримується як єдине ціле (неможливе ефективне агрегування на стовпцях / полях).

Збиває з пантелику те, що «рядок» із широкими стовпцями можна легко представити як документ, але, як уже зазначалося, вони зберігаються по-різному та оптимізовані для різних цілей.