Статистика в реальном времени: MySQL(/Drizzle) или MongoDB?
Мы работаем над проектом, в котором в реальном времени будет отображаться статистика некоторых действий (например, кликов). При каждом клике мы будем регистрировать информацию, такую как дата, возраст и пол (они поступают из Facebook), местоположение и т. Д.
Мы обсуждаем лучшее место для хранения этой информации и использования ее для статистики в реальном времени. Мы будем отображать совокупную статистику: например, количество кликов, количество кликов, сделанных мужчинами / женщинами, количество кликов, разделенное на возрастные группы (например, 18-24, 24-30...).
Так как на сайте мы используем MongoDB везде, мой коллега решил, что мы должны хранить статистику и внутри него. Я, однако, предпочел бы базу данных на основе SQL для этой задачи, например MySQL (или, возможно, Drizzle), потому что я считаю, что SQL лучше выполнять при выполнении таких операций, как агрегирование данных. Несмотря на то, что анализ SQL требует больших затрат, я думаю, что MySQL/Drizzle на самом деле может быть быстрее, чем базы данных No-SQL. И вставки тоже не медленные, когда используются запросы INSERT DELAYED.
Обратите внимание, что нам не нужно выполнять JOINS или собирать данные из нескольких таблиц / коллекций. Таким образом, нам все равно, если база данных отличается. Тем не менее, мы заботимся о масштабируемости и надежности. Мы создаем что-то, что (надеюсь) станет очень большим, и мы разработали каждую строку кода с учетом масштабируемости.
Что Вы думаете об этом? Есть ли причина предпочитать MongoDB MySQL/Drizzle для этого? Или это безразлично? Какой бы вы использовали, если бы вы были нами?
Спасибо алессандро
2 ответа
Итак, 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 } }, Вы можете обновить весь документ атомарно. И на самом деле довольно естественно сообщать. У вас уже есть массив, содержащий ваши точки почасового или минутного уровня данных.
Надеюсь, это указывает на правильное направление.
MongoDB отлично подходит для такого рода вещей и, безусловно, будет быстрее, чем MySQL, хотя не стоит недооценивать, насколько мощным может быть MySQL - многие компании создали аналитические инструменты с ним.
Посмотрите на эту презентацию Патрика Стоукса из BuddyMedia о том, как они использовали MongoDB для своей аналитической системы.
http://www.slideshare.net/pstokes2/social-analytics-with-mongodb