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

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

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

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

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

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

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

В 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, но вы не получите всех функций настоящего хранилища, ориентированного на документы.

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

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

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

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

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

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

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