Что означает «Ориентированный на документ» против Key-Value, когда речь идет о MongoDB против Cassandra?

Question

Что означает «Ориентированный на документ» против Key-Value, когда речь идет о MongoDB против Cassandra?

99

Что происходит с опцией NoSQL на основе документа, покупающей вас через KV-магазин и наоборот?

tesserakt 15 июнь 2010, в 14:57

Источник

0

дубликат stackoverflow.com/questions/3046390/…
killjoy 27 март 2015, в 02:09

Теги:

mongodb

cassandra

nosql

3 ответа

11

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

KV-магазины не знают о ценности содержимое, фактически сохраненное для ключа
На основе документа вы можете определить индексов в пределах значения, db знает структуру документа (например, теги сообщения в блоге).
Решения NoSQL имеют специфические особенности, которые следует учитывать, например
- Специальные типы данных в хранилище KV (например, устанавливает с левым/правым pop/push как в redis)
- простой масштабируемый кластер вверх/вниз, поскольку riak говорит, что он (я не пытался его еще...)
- подключаемое хранилище данных, как в Voldemort
- встроенная веб-конфигурация и поддержка веб-приложений, например, в CouchDB/couchapp

Niels Wind 19 июнь 2010, в 17:45

0

Документированная база данных или хранилище документов предназначена для хранения, извлечения и управления документально-ориентированной информацией, которая представляет собой полуструктурированные данные. Хранилище ключевого значения наследует базу данных, ориентированную на документы. Разница заключается в том, как обрабатываются данные; в хранилище значений ключа данные считаются непрозрачными для базы данных, тогда как документально ориентированная система опирается на внутреннюю структуру документа, чтобы извлекать метаданные, которые использует механизм базы данных для дальнейшей оптимизации.

Если мы поговорим о различии между MOngoDb и Cassandra. MongoDB действует как реляционная база данных. Его модель данных состоит из базы данных на верхнем уровне, а затем коллекции, похожие на таблицы в MySQL (например), а затем документы, которые содержатся в коллекции, например строки в MySQL. Каждый документ имеет поле и значение, где это похоже на столбцы и значения в MySQL. Поля могут быть простым ключом/значением, например. {'name': 'David Mytton'}, но они также могут содержать другие документы, например. {'name': {'first': David, 'last': 'Mytton'}}. В документах Cassandra известны как "столбцы", которые на самом деле являются всего лишь одним ключом и ценностью. например {'key': 'name', 'value': 'David Mytton'}. Theres также поле временной метки, которое предназначено для внутренней репликации и согласованности. Значение может быть единственным значением, но может также содержать другой "столбец". Эти столбцы затем существуют в семействах столбцов, которые упорядочивают данные на основе определенного значения в столбцах, на которые ссылается ключ.

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

Nandan Priyadarshi 05 май 2016, в 08:19

Ещё вопросы

Pascal Thivent · Accepted Answer · 2010-06-19T19-34-00.000Z

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

Документированная база данных расширяет предыдущую модель, и значения хранятся в структурированном формате (документ, следовательно, имя), которое может понять база данных. Например, документ может быть в блоге и комментариями и тегами, хранящимися в денормализованном виде. Поскольку данные прозрачны, хранилище может выполнять больше работы (например, поля индексирования документа), и вы не ограничены запросом по ключу. Как я и намекал, такие базы данных позволяют получать целые страницы с одним запросом и хорошо подходят для контент-ориентированных приложений (вот почему такие крупные сайты, как Facebook или Amazon, похожи на них).

Другие типы баз данных NoSQL включают в себя хранилища, ориентированные на столбцы, базы данных графов и даже базы данных объектов. Но это выходит за рамки вопроса.

См. также

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