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

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

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

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

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

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

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

Ответ 1

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

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

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

Смотрите также этот вопрос: Cassandra: что такое подколонка

Или ссылки моделирования данных из http://wiki.apache.org/cassandra/ArticlesAndPresentations

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

Значения столбца Cassandra являются просто байтами, но могут быть введены как текст ASCII, UTF8, числа, даты и т.д.

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

Ответ 2

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

Ответ 3

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

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

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

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