Как структурировать модель данных для рекламного инструмента в MongoDB

Question

Я создаю инструмент аналитики рекламы, который предполагает структуру данных, подобную этой:

• Аккаунт
• Кампания
• Ключевое слово
• Конверсия

У меня много информации об отдельных событиях конверсии, которую можно связать с данными о стоимости каждой кампании, ключевого слова, группы объявлений и т. Д. В SQL вы можете рассматривать каждое свойство как своего родавнешний ключ (текстовый) для кампании, ключевого слова или рекламы в определенном аккаунте, но это неэффективно и медленно.Не похоже, что это хорошая идея - заполнять поля campaign_id, keyword_id и т. Д. И заполнять их, потому что я хочу, чтобы аналитика была доступна почти в реальном времени.

Что было бы хорошим способомсмоделировать это с MongoDB?

Answer 1

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

Варианты бесплатного / открытого источника, которые я могу предложить, это Hadoop (и, вероятно, HBase и Hive) или Riak.Есть и другие варианты - я предлагаю только эти два, потому что у меня есть личный опыт работы с ними в масштабной производственной среде.В настоящее время мы используем Hadoop для обеспечения работы аналитической системы, обрабатывающей миллиарды событий в день.

Если вы не хотите заниматься своими делами и способны и готовы платить (много!), Тогда взгляните на GreenPlum иVertica.

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

Answer 2

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

Я не знаю, какими будут ваши объемы и какие другие факторы влияют на ваш технологический выбор. Однако, предполагая, что ваши учетные записи, кампании и ключевые слова не меняются , а часто, вы могли бы сделать это с помощью простой старой СУБД (SQL или Oracle и т. Д.), Используя таблицы поиска для этих определителей, где внешние ключи не имеют смысла целые числа. Если вы выполняете аналитику в режиме реального времени, вы можете принять звездообразную схему и сохранить все числовые FK в базовой таблице фактов (преобразование), чтобы вы не объединяли цепочку из четырех таблиц, чтобы получить полную картину, вместо этого вы бы делать три соединения одним прыжком. Это позволит вам суммировать на любом уровне только с одним соединением.