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

Question

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

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

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

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

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

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

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

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

Answer 2

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

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

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