Блог

Мы работаем над проектом, который будет отображать статистику некоторых действий (например, кликов) в реальном времени. При каждом нажатии мы будем регистрировать такую информацию, как дата, возраст и пол (они поступают с Facebook), Местоположение и т.д.

Мы обсуждаем, где лучше хранить эту информацию и использовать ее для статистики в реальном времени. Мы будем отображать совокупную статистику: например, количество кликов, количество кликов, сделанных мужчинами / женщинами, количество кликов, разделенных по возрастным группам (например, 18-24, 24-30 …).

Поскольку на сайте мы повсеместно используем MongoDB, мой коллега подумал, что нам следует хранить статистику и внутри него. Я, однако, предпочел бы базу данных на основе SQL для этой задачи, такую как MySQL (или, возможно, Drizzle), потому что я считаю, что SQL лучше при выполнении операций, таких как агрегирование данных. Хотя разбор SQL сопряжен с накладными расходами, я думаю, что MySQL / Drizzle на самом деле может быть быстрее, чем базы данных без SQL. И вставки тоже не замедляются при использовании запросов С ЗАДЕРЖКОЙ ВСТАВКИ.

Пожалуйста, обратите внимание, что нам не нужно выполнять ОБЪЕДИНЕНИЯ или собирать данные из нескольких таблиц / коллекций. Таким образом, нам все равно, отличается ли база данных. Тем не менее, мы заботимся о масштабируемости и надежности. Мы создаем что-то, что (надеюсь) станет очень большим, и мы разработали каждую строку кода с учетом масштабируемости.

Что вы думаете по этому поводу? Есть ли какая-либо причина предпочесть MongoDB вместо MySQL / Drizzle для этого? Или это безразлично? Какую из них вы бы использовали на нашем месте?

Спасибо, Алессандро

Итак, BuddyMedia использует что-то из этого. Группа Gilt сделала кое-что довольно крутое с Hummingbird (node.js MongoDB).

Работая на крупного онлайн-рекламодателя в пространстве социальных сетей, я могу подтвердить, что отчетность в реальном времени — это действительно боль. Попытка «накапливать» 500 МИЛЛИОНОВ показов в день уже является сложной задачей, но попытка сделать это в режиме реального времени сработала, но имела некоторые существенные ограничения. (как будто это действительно было отложено на 5 минут 🙂

Честно говоря, такого рода проблемы — одна из причин, по которой я начал использовать MongoDB. И я не единственный. Люди используют MongoDB для всех видов аналитики в реальном времени: мониторинга сервера, централизованного ведения журнала, а также отчетов на панели мониторинга.

Главное при создании отчетов такого типа — понимать, что структура данных в MongoDB совершенно иная, вы собираетесь избегать запросов «агрегации», поэтому запросы и выходные диаграммы будут другими. На стороне клиента выполняется дополнительная работа по кодированию.

Вот ключ, который может указать вам правильное направление для выполнения этого с MongoDB. Взгляните на следующую структуру данных:

 {
  date: "20110430",
  gender: "M",
  age: 1, // 1 is probably a bucket
  impression_hour: [ 100, 50, ...], // 24 of these
  impression_minute: [ 2, 5, 19, 8, ... ], // 1440 of these
  clicks_hour: [ 10, 2, ... ],
  ...
}
  

Очевидно, что здесь есть некоторые настройки, соответствующие индексы, возможно, объединение данных пол возраст в _id . Но это своего рода базовая структура аналитики кликов с MongoDB. Действительно легко обновлять показы и клики { $inc : { clicks_hour.0 : 1 } } . Вы можете обновлять весь документ атомарно. И это на самом деле довольно естественно для отчетов. У вас уже есть массив an, содержащий ваши данные на уровне часов или минут.

Надеюсь, это указывает вам правильное направление.

MongoDB отлично подходит для такого рода задач и, безусловно, будет быстрее, чем MySQL, хотя не стоит недооценивать, насколько мощным может быть MySQL — многие компании создали аналитические инструменты с его помощью.

Взгляните на презентацию Патрика Стокса из BuddyMedia о том, как они использовали MongoDB для своей аналитической системы.

http://www.slideshare.net/pstokes2/social-analytics-with-mongodb