Хранилище « ключ-значение» обеспечивает простейшую возможную модель данных, и именно это подразумевает название: это система хранения, в которой хранятся значения, индексированные по ключу. Вы ограничены запросом по ключу, а значения непрозрачны , магазин ничего о них не знает . Это позволяет выполнять очень быстрые операции чтения и записи (простой доступ к диску), и я рассматриваю эту модель как своего рода энергонезависимый кеш (т.е. хорошо подходит, если вам нужен быстрый доступ по ключу к долгоживущим данным).
Базы данных документ-ориентированный расширяет предыдущую модель и значения сохраняются в структурированном формате (документ, отсюда и название) , что база данных может понять. Например, документ может быть записью в блоге, а комментарии и теги хранятся денормализованным образом. Поскольку данные прозрачны , хранилище может выполнять больше работы (например, индексировать поля документа), и вы не ограничены запросом по ключу. Как я намекнул, такие базы данных позволяют получить данные всей страницы с помощью одного запроса и хорошо подходят для контент-ориентированных приложений (именно поэтому они нравятся крупным сайтам, таким как Facebook или Amazon).
Другие типы баз данных NoSQL включают хранилища , ориентированные на столбцы , базы данных графов и даже базы данных объектов . Но это не подлежит сомнению.
Хранилища ключей и значений не обязательно должны выполняться с доступом к диску, и называть их энергонезависимыми некорректно в некоторых реализациях. Вы можете создать в памяти хранилище ключей и значений без сквозной или обратной записи на энергонезависимый носитель. Называть данные долгоживущими также вводит в заблуждение, потому что время жизни данных не имеет ничего общего с тем, как вы их извлекаете.
Энтони
17
Ну, я сам исследовал NoSQL последний месяц или около того. Я думаю, что в общем можно было бы сказать что-то вроде
KV store не знает, какое значение фактически хранится для ключа.
На основе документа позволяет вам определять вторичные индексы в содержимом значений, поскольку база данных знает структуру документа (например, теги сообщения в блоге).
Каждое решение NoSQL имеет определенные особенности, которые следует учитывать, например:
Специальные типы данных в хранилище KV (например, наборы с левым / правым pop / push, как в Redis)
легко масштабировать вверх / вниз кластер, как говорит Риак (я не пробовал ... пока)
подключаемое хранилище данных как в Voldemort
встроенная веб-конфигурация и поддержка веб-приложений, как в CouchDB / couchapp
Документно-ориентированная база данных или хранилище документов предназначены для хранения, извлечения и управления документально-ориентированной информацией, которая представляет собой полуструктурированные данные. Хранилище ключей и значений наследуется от документ-ориентированной базы данных. Разница заключается в способе обработки данных; в хранилище "ключ-значение" данные считаются непрозрачными для базы данных, тогда как система, ориентированная на документы, полагается на внутреннюю структуру документа для извлечения метаданных, которые механизм базы данных использует для дальнейшей оптимизации.
Если говорить о разнице между MOngoDb и Cassandra. MongoDB действует как реляционная база данных. Его модель данных состоит из базы данных на верхнем уровне, затем коллекций, которые похожи на таблицы в MySQL (например), а затем документов, которые содержатся в коллекции, например, строк в MySQL. Каждый документ имеет поле и значение, подобное столбцам и значениям в MySQL. Поля могут представлять собой простые пары ключ / значение, например {'name': 'David Mytton'}, но они также могут содержать другие документы, например {'name': {'first': David, 'last': 'Mytton'}}. В Cassandra документы известны как «столбцы», которые на самом деле представляют собой всего лишь один ключ и значение. например {'ключ': 'имя', 'значение': 'Дэвид Миттон'}. Также есть поле временной метки, предназначенное для внутренней репликации и согласованности. Значение может быть одним значением, но может также содержать другой «столбец». Эти столбцы затем существуют в семействах столбцов, которые упорядочивают данные на основе определенного значения в столбцах, на которое ссылается ключ.
Но на верхнем уровне есть пространство ключей, которое похоже на базу данных MongoDB.
В модели базы данных «ключ-значение» пользователи могут выбирать ключи, тогда как идентификаторы документов в модели документа обычно генерируются системой.
Пары ключ-значение в модели базы данных ключ-значение не могут быть сгруппированы, тогда как в базе данных документов мы можем группировать пары ключ-значение в отдельные документы; более того, некоторые формы баз данных документов позволяют нам даже дополнительно группировать эти документы, а именно в так называемые «коллекции» или «домены».
Хотя документы в базе данных документов имеют внутреннюю структуру, которая четко определена (и, таким образом, с ними может работать СУБД, например, для создания индексов), то же самое не относится к значениям в пар ключ-значение. база данных, в которой любая возможная внутренняя структура таких значений непрозрачна с точки зрения СУБД.
В модели «ключ-значение» для доступа к нескольким записям базы данных (в данном случае парам «ключ-значение») требуются отдельные запросы. В модели документа, с другой стороны, несколько записей базы данных (в данном случае документы) могут быть получены в одном запросе.
Ответы:
Хранилище « ключ-значение» обеспечивает простейшую возможную модель данных, и именно это подразумевает название: это система хранения, в которой хранятся значения, индексированные по ключу. Вы ограничены запросом по ключу, а значения непрозрачны , магазин ничего о них не знает . Это позволяет выполнять очень быстрые операции чтения и записи (простой доступ к диску), и я рассматриваю эту модель как своего рода энергонезависимый кеш (т.е. хорошо подходит, если вам нужен быстрый доступ по ключу к долгоживущим данным).
Базы данных документ-ориентированный расширяет предыдущую модель и значения сохраняются в структурированном формате (документ, отсюда и название) , что база данных может понять. Например, документ может быть записью в блоге, а комментарии и теги хранятся денормализованным образом. Поскольку данные прозрачны , хранилище может выполнять больше работы (например, индексировать поля документа), и вы не ограничены запросом по ключу. Как я намекнул, такие базы данных позволяют получить данные всей страницы с помощью одного запроса и хорошо подходят для контент-ориентированных приложений (именно поэтому они нравятся крупным сайтам, таким как Facebook или Amazon).
Другие типы баз данных NoSQL включают хранилища , ориентированные на столбцы , базы данных графов и даже базы данных объектов . Но это не подлежит сомнению.
Смотрите также
источник
Ну, я сам исследовал NoSQL последний месяц или около того. Я думаю, что в общем можно было бы сказать что-то вроде
источник
Документно-ориентированная база данных или хранилище документов предназначены для хранения, извлечения и управления документально-ориентированной информацией, которая представляет собой полуструктурированные данные. Хранилище ключей и значений наследуется от документ-ориентированной базы данных. Разница заключается в способе обработки данных; в хранилище "ключ-значение" данные считаются непрозрачными для базы данных, тогда как система, ориентированная на документы, полагается на внутреннюю структуру документа для извлечения метаданных, которые механизм базы данных использует для дальнейшей оптимизации.
Если говорить о разнице между MOngoDb и Cassandra. MongoDB действует как реляционная база данных. Его модель данных состоит из базы данных на верхнем уровне, затем коллекций, которые похожи на таблицы в MySQL (например), а затем документов, которые содержатся в коллекции, например, строк в MySQL. Каждый документ имеет поле и значение, подобное столбцам и значениям в MySQL. Поля могут представлять собой простые пары ключ / значение, например {'name': 'David Mytton'}, но они также могут содержать другие документы, например {'name': {'first': David, 'last': 'Mytton'}}. В Cassandra документы известны как «столбцы», которые на самом деле представляют собой всего лишь один ключ и значение. например {'ключ': 'имя', 'значение': 'Дэвид Миттон'}. Также есть поле временной метки, предназначенное для внутренней репликации и согласованности. Значение может быть одним значением, но может также содержать другой «столбец». Эти столбцы затем существуют в семействах столбцов, которые упорядочивают данные на основе определенного значения в столбцах, на которое ссылается ключ.
Но на верхнем уровне есть пространство ключей, которое похоже на базу данных MongoDB.
источник
В модели базы данных «ключ-значение» пользователи могут выбирать ключи, тогда как идентификаторы документов в модели документа обычно генерируются системой.
Пары ключ-значение в модели базы данных ключ-значение не могут быть сгруппированы, тогда как в базе данных документов мы можем группировать пары ключ-значение в отдельные документы; более того, некоторые формы баз данных документов позволяют нам даже дополнительно группировать эти документы, а именно в так называемые «коллекции» или «домены».
Хотя документы в базе данных документов имеют внутреннюю структуру, которая четко определена (и, таким образом, с ними может работать СУБД, например, для создания индексов), то же самое не относится к значениям в пар ключ-значение. база данных, в которой любая возможная внутренняя структура таких значений непрозрачна с точки зрения СУБД.
В модели «ключ-значение» для доступа к нескольким записям базы данных (в данном случае парам «ключ-значение») требуются отдельные запросы. В модели документа, с другой стороны, несколько записей базы данных (в данном случае документы) могут быть получены в одном запросе.
источник