Производительность хранения данных Mongodb - один документ с элементами в массиве против нескольких документов на элемент

Question

У меня есть статистические данные в коллекции Mongodb, сохраненные для каждой записи в день. Например, моя коллекция выглядит примерно так:

{ record_id: 12345, date: Date(2011,12,13), stat_value_1:12345, stat_value_2:98765 }

Каждая запись / идентификатор / дата уникальны. Я запрашиваю коллекцию, чтобы получить статистику по каждой записи для заданного диапазона дат, используя map-Reduce.

Что касается производительности запросов на чтение, то эта стратегия лучше, чем хранение одного документа на запись_ид, содержащего массив статистических данных, как указано выше:

{ _id: record_id, stats: [
{ date: Date(2011,12,11), stat_value_1:39884, stat_value_2:98765 },
{ date: Date(2011,12,12), stat_value_1:38555, stat_value_2:4665 },
{ date: Date(2011,12,13), stat_value_1:12345, stat_value_2:265 },
]}

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

Answer 1

Я думаю, это зависит от сценария использования. Если набор данных для одной агрегации небольшой, как эти 700 записей, и вы хотите сделать это в режиме реального времени, я думаю, что лучше выбрать еще один вариант и запросить все отдельные записи и агрегировать их на стороне клиента. Это позволяет избежать накладных расходов Map / Reduce, проще в обслуживании и не страдает от перераспределения или ограничений по размеру. Использование индексов должно быть эффективным и с точки зрения соединения, я сомневаюсь, что есть большая разница: большинство драйверов в любом случае выполняют пакетную передачу.

Дополнительная гибкость может пригодиться, например, если вы хотите узнать значение статистики за один день для всех записей (если это когда-либо имеет смысл для вашего приложения). Если вам когда-либо понадобится хранить больше stat_values, максимальное количество дат для каждой записи будет уменьшено в рамках подхода с поддокументами. Также, как правило, проще работать с документами БД, чем с под-документами.

Map / Reduce действительно сияет, если вы собираете огромные объемы данных на нескольких серверах, в противном случае пропускная способность и параллелизм клиента могут стать узкими местами.

Answer 2

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