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

Question

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

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

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

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

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

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

Answer 1

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

Answer 2

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

В некоторых случаях у вас может быть очень большое количество столбцов в строке (например, в качестве индекса для включения определенных типов запросов). 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, - но вы не получите все функции реального ориентированного на документы хранилища.

Answer 3

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

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

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

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