Статистика в реальном времени: MySQL (/Дождь) или MongoDB?

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

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

Так как на сайте мы везде используем MongoDB, мой коллега подумал, что мы должны хранить статистику внутри него. Однако я предпочел бы базу данных на базе SQL для этой задачи, такую как MySQL (или, возможно, "Дождь" ), потому что я считаю, что SQL лучше при выполнении операций, таких как агрегация данных. Несмотря на накладные расходы на разбор SQL, я думаю, что MySQL/Drizzle может быть быстрее, чем базы данных No-SQL. И вставки также не слишком медленны при использовании запросов INSERT DELAYED.

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

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

Спасибо, Alessandro

Ответ 1

Итак, BuddyMedia использует часть этого. Gilt Groupe сделала что-то довольно классное с 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. Но такая базовая структура аналитики click с MongoDB. Очень легко обновить впечатление и клики { $inc : { clicks_hour.0 : 1 } }. Вы можете обновить весь документ атомарно. И на самом деле довольно естественно отчитываться. У вас уже есть массив, содержащий ваши часовые или минутные точки данных.

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

Ответ 2

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

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

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