Чем NoSQL, ориентированный на столбцы, отличается от ориентированного на документы?

90

Я читал о трех типах баз данных NoSQL: «ключ-значение», ориентированных на столбцы и ориентированных на документы.

Пары "ключ-значение" довольно просты - ключ с простым значением.

Я видел документно-ориентированные базы данных, описанные как ключ-значение, но значение может быть структурой, например, объектом JSON. Каждый «документ» может иметь все, некоторые или ни один из тех же ключей, что и другой.

Ориентация на столбцы очень похожа на документ, ориентированный на то, что вы не указываете структуру.

Итак, в чем разница между этими двумя и почему вы должны использовать одно вместо другого?

Я специально посмотрел на MongoDB и Cassandra. Мне в основном нужна динамическая структура, которая может изменяться, но не влияет на другие значения. В то же время мне нужно иметь возможность искать / фильтровать определенные ключи и создавать отчеты. С CAP для меня важнее всего AP. Данные могут «в конечном итоге» синхронизироваться между узлами при условии отсутствия конфликта или потери данных. У каждого пользователя будет своя «таблица».

Люк
источник

Ответы:

41

В Cassandra каждая строка (адресуемая ключом) содержит один или несколько «столбцов». Столбцы сами по себе представляют собой пары "ключ-значение". Имена столбцов необязательно определять заранее, т.е. структура не фиксирована. Столбцы в строке хранятся в отсортированном порядке в соответствии с их ключами (именами).

В некоторых случаях у вас может быть очень большое количество столбцов в строке (например, чтобы действовать как индекс, чтобы разрешить определенные виды запросов). Cassandra может эффективно обрабатывать такие большие структуры, и вы можете извлекать определенные диапазоны столбцов.

Существует еще один уровень структуры (не так часто используемый), называемый суперколонками, где столбец содержит вложенные (под) столбцы.

Вы можете думать об общей структуре как о вложенной хэш-таблице / словаре с 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

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

Значения столбца Cassandra - это просто байты, но их можно вводить как текст ASCII, UTF8, числа, даты и т. Д.

Конечно, вы можете использовать Cassandra в качестве примитивного хранилища документов, вставляя столбцы, содержащие JSON, но вы не получите всех функций настоящего хранилища, ориентированного на документы.

ДНК
источник
5
Семейство столбцов похоже на таблицу. Строка похожа на строку таблицы. Столбцы похожи на столбцы базы данных, за исключением того, что они могут быть определены на лету, поэтому в некоторых случаях у вас может быть очень мало заполненная таблица или у вас могут быть разные столбцы, заполненные в каждой строке.
DNA
1
Это зависит от базы данных. В MongoDB (ориентированном на документы) вы также можете обновить каждый ключ.
Дэвид Рааб
1
Если это правда, то как MongoDB определяет базу данных, ориентированную на документы, тогда как Cassandra ориентирована на столбцы. Насколько они разные?
Люк,
3
@Luke Ориентированная на столбцы выглядит очень похоже на РСУБД без схемы, но, помимо ее рыхлой структуры, основное отличие состоит в том, что она не является реляционной.
user327961
1
@ user327961 Но MongoDB также похожа на СУБД без схемы, и она также не реляционная.
huggie
55

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

Тео
источник
В этом случае монго (документ) может делать то же, что и кассендра (столбец). Зачем тогда нужна колонка?
Санджай Патель
1
Это компромисс между различными функциями: с ориентированной на столбцы конструкцией механизм хранения может быть намного более эффективным, чем механизм хранения, ориентированный на документы. MongoDB должен переписать весь документ на диске, если он становится больше, но Cassandra не обязана (это упрощение, конечно, здесь много деталей). Это делает Cassandra намного быстрее, когда дело доходит до письма.
Тео,
29

В «вставке», если использовать слова rdbms, «Document-based» более последовательный и прямой подход. Обратите внимание, что cassandra позволяет добиться согласованности с понятием кворума, но это не относится ко всем системам на основе столбцов и снижает доступность. В системе с интенсивной однократной записью / частым чтением выберите MongoDB. Также учитывайте это, если вы всегда планируете читать всю структуру объекта. Система на основе документов предназначена для возврата всего документа, когда вы его получаете, и не очень сильна при возврате частей всей строки.

Системы на основе столбцов, такие как Cassandra, намного лучше, чем основанные на документах "обновления". Вы можете изменить значение столбца, даже не читая строку, которая его содержит. Запись на самом деле не обязательно должна выполняться на одном сервере, строка может содержаться в нескольких файлах на нескольких серверах. В огромной, быстро развивающейся системе данных выберите Cassandra. Также подумайте об этом, если вы планируете иметь очень большой объем данных для каждого ключа, и вам не нужно загружать их все при каждом запросе. В «select» Cassandra позволяет загружать только нужный столбец.

Также учтите, что Mongo DB написана на C ++ и находится на втором основном выпуске, тогда как Cassandra должна работать на JVM, а его первый основной выпуск находится в кандидате на выпуск только со вчерашнего дня (но выпуски 0.X превратились в производство уже крупная компания).

С другой стороны, разработка Cassandra была частично основана на Amazon Dynamo, и по своей сути она построена как решение высокой доступности, но это не имеет ничего общего с форматом на основе столбцов. MongoDB тоже масштабируется, но не так изящно, как Cassandra.

user327961
источник
1
Что плохого в том, что часть программного обеспечения написана на C ++, а не на Java?
Наюки
@Nayuki Теперь я знаю, что существуют высококонкурентные рабочие нагрузки, в которых ленивая сборка мусора модели управления памятью Java теоретически превосходит «ручную» модель управления C ++, но, вообще говоря, обычно нетрудно превзойти Java, написав эквивалент программа на C ++, по крайней мере, пока вы отключите исключения и RTTI. И если вы хорошо используете бесстековые сопрограммы и возобновляемые функции, что ж, я лично еще не видел, чтобы Java превзошла мой C ++.
patrickjp93
0

Я бы сказал, что основное различие заключается в том, как каждый из этих типов БД физически хранит данные.
С типами столбцов данные хранятся по столбцам, которые могут обеспечить эффективные операции / запросы агрегирования для определенного столбца.
С типами документов весь документ логически хранится в одном месте и обычно извлекается целиком (эффективное агрегирование по «столбцам» / «полям» невозможно).

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

Майкл
источник