Как реализованы хранилища данных на основе документов (например, Mongo) по сравнению с хранилищем значений ключей?

Question

В последнее время я немного читал о базах данных на основе документов и хранилищах значений ключей (Вот хороший обзор Разница между базами данных на основе документов и ключами / значениями? ) и I 'Я не могу найти хорошую информацию о следующем.

Если мы запросим любой из них с помощью ключа (или дополнительного индекса), в механике нет никакой разницы - получим значение.Мне не ясно, чем хранилище документов отличается от хранилища значений ключей при запросах неиндексированных документов / полей.Если бы я реализовал хранилище документов поверх хранилища ключ-значение, я бы сделал «сканирование таблицы» (проверил все пары ключ / значение) для соответствующего значения в запросе - хранилища документов делают больше, чем это вчехлы?Уместно ли думать о хранилищах данных документов таким образом?

Это менее практический вопрос (я бы использовал Mongo поверх BDB, если бы мне нужно было сделать что-то полезное, скорее всего), чем вопрос, направленный на понимание базовой технологии.Меня интересуют аспекты масштабирования отдельных систем, только если они применимы к базовой реализации.

Answer 1

MongoDB и CouchDB используют стандарт JSON ( или BSON ( spec )) для хранения данных. Они оптимизировали алгоритмы, когда вы запрашиваете определенное значение объекта, и, насколько мне известно, они используют Binary Tree s для оптимизации с индексами ( MongoDB, безусловно, делает ). Используя их, они могут найти данные несравнимо быстрее, чем поиск по значениям в базе данных пар ключ-значение.

(Из реализаций базы данных пар ключ-значение Redis имеет очень интересный способ повышения производительности, когда он сохраняет данные в памяти с небольшим количеством дисковых операций ввода-вывода.)

Edit:

Пришло отличное видео , в котором объясняются внутренности MongoDB. Проверьте это .

Answer 2

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

Механизмы, основанные на документах, добавляют поддержку путей элементов в документе (или как они там это называются).По сути, вы можете эмулировать хранилище значений ключей, создав документ {key, value} из значения ключа.Если вы используете только для запроса документов с использованием структуры ключа, у вас в основном такой же результат и аналогичные оптимизации с точки зрения поиска.

Чтобы найти информацию о внутренностях mongoDB, вы могли бы использовать их сайт и искать внутренние компоненты (https://www.mongodb.com/search?search=internals). Много информации можно найти.

Answer 3

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

Аспекты, которые необходимо принять во внимание:

-Частота записи по сравнению с операциями чтения

- Необходим для анализа данных

- избыточность данных для высокой доступности

- репликация / синхронизация данных

-Нужно много переходных данных

- размер данных

- готов к облачности

Некоторые реализации NonSQL поддерживают эти аспекты лучше по отдельности, чем другие.

Сценарии:

- часто записываемые, редко читаемые данные, такие как счетчики посещений сети, или данные с регистрирующих устройств: Redis | MongoDB

-Часто читаемые, редко записываемые / обновляемые: Memcached для временного кэширования данных, Cassandra | HBase для поиска и Hadoop и Hive для анализа данных

- Приложения высокой доступности, требующие минимального времени простоя, хорошо работают с кластерными избыточными хранилищами данных: Riak | Cassandra

- синхронизация данных в нескольких местах: CouchDB

-Временные данные (веб-сеансы и кэши) хорошо работают в хранилищах временных данных: Memcached

-Большие данные, полученные из бизнес-аналитики или веб-аналитики, которые могут не соответствовать какой-либо очевидной схеме: Hadoop

Вывод:

ИМХО, вам следует сосредоточиться на проблеме выбора масштабируемого хранилища данных, начиная со сценария использования, а не на основных аспектах и ​​различиях между ними.

Я также рекомендую вам проверить Couchbase , которая является хорошей комбинацией двух миров: основанных на ключах и ориентированных на документы.