Рекомендации по модели данных для коллекции Mongo, которая содержит сложные объекты

Question

Мы храним данные приложения Apple в базе данных (http://www.apple.com/itunes/affiliates/resources/documentation/itunes-enterprise-partner-feed.html).

Мы хотим оптимизировать для одного типа запросов: найти все приложения, соответствующие определенным критериям. критерии: (1) средний рейтинг приложения; (2) количество рейтингов приложений; (3) устройства, поддерживаемые приложением; (4) страны, в которых продается приложение; (5) текущая цена приложения; и (6) дата, когда приложение поступило бесплатно. запрос должен быть как можно быстрее. Пример запроса: «найти все приложения с рейтингом 600, в среднем 5 звезд, поддерживает iPads и iPhone, продается в США и снизил их цену до $ 0.00 два дня назад».

на основе схемы яблока, есть информация о ценах для каждой страны. предполагая, что яблоко поддерживает 100 стран, каждое приложение будет иметь 100 цен - по одному для каждой страны. мы также должны хранить исторические цены для каждого приложения, то есть приложение с 10 изменениями цены будет иметь 1000 цен (в случае 100 стран).

три вопроса:

1) как вы посоветуете нам хранить данные о ценах в Монго, чтобы сделать запросы быстро? прямо сейчас, мы думаем хранить цены в виде массива объектов. каждый объект состоит из трех элементов: (1) дата; (2) страна; (3) цена.

2) если мы храним данные о ценах как объекты в массиве, что нам нужно сделать, чтобы сделать поиск по данным цены очень быстрым. опять же, общий поиск цен - это нечто вроде «найти все приложения, которые снизили свою цену до $ 0.00 2 дня снова в магазине США».

3) любые ошибки, которые мы должны помнить при хранении данных?

Answer 1

Лично у меня будет отдельная коллекция ежедневных данных о ценах - 1 запись в день за приложение (составной натуральный ключ), с набором из 100 номеров для этого приложения. Таким образом, записи никогда не должны расти или перемещаться - это большая победа. При правильном индексировании большинство запросов к этой коллекции могут быть выполнены для того, чтобы хорошо работать. Сохраняйте имена полей небольшими для более эффективного хранения.

Я бы сохранил отдельную коллекцию для приложения «основные данные» - 1 запись за приложение. В этих записях вы можете вспомнить самую последнюю дату, когда приложение стало бесплатным, снимок самого последнего ценового вектора по стране и аналогичные значения моментальных снимков любых других «сводных» данных, которые могут формировать критерии выбора для поиска приложений. Агрегации для вычисления и записи таких значений, если они могут стать дорогостоящими, могут затем выполняться в фоновом режиме в удобное время.

Надеюсь, что это поможет! Отлично, что вы задаете эти вопросы заранее. :)