Структура базы данных для аналитики сайта с использованием MongoDB

Question

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

Когда пользователь посещает веб-сайт, ему необходимо записать стандартную информацию (IP-адрес, данные браузера, идентификатор веб-сайта, URL-адрес, имя пользователя). Также необходимо записывать каждую последующую страницу, которую посещает пользователь (текущая метка времени, URL). Если пользователь покидает веб-сайт и возвращается через 10 дней, ему необходимо зарегистрировать это посещение, а также указать, что он является вернувшимся пользователем (определяется по имени пользователя).

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

Как побочная мысль, было бы неплохо, если бы в будущем она могла предоставлять отчеты в режиме реального времени, но это выходит за рамки текущего проекта.

Теперь я прочитал статью на http://blog.mongodb.org/post/171353301/using-mongodb-for-real-time-analytics, но в ней ничего не говорится о веб-сайтах с высоким трафиком - он может быть способен справиться с несколькими тысячами записей, насколько мне известно. Следую ли я концепции этой должности и извлекаю отчеты непосредственно из этой коллекции, или было бы лучше предварительно проанализировать данные и заархивировать их в отдельную коллекцию?

Буду очень признателен за любые мысли о вставке данных, структуре базы данных и отчетности!

Answer 1

(MySQL) недостаточно для моих нужд (с точки зрения масштабируемости, скорости и т. Д.)

Что ж ... похоже, Facebook в большой степени использует MySQL.Когда дело доходит до NoSQL, я считаю, что это не обязательно технология, это структуры данных и алгоритмы.

---

Вы столкнулись с ситуацией с потенциально высокой пропускной способностью записи. sharding . Один из подходов к высокой пропускной способности записи, который хорошо соответствует вашей проблеме, - независимо от того, насколько велика машина и насколько эффективно программное обеспечение, будет ограничено число записей, записываемых однойМашина может справиться.Sharding распределяет данные по нескольким серверам, поэтому вы можете записывать их на разные серверы.Например, пользователи AM выполняют запись на сервер 1, пользователи NZ - на сервер 2.

Теперь разделение происходит за счет сложности, поскольку требует балансировки, агрегации по всем разделам могут быть сложными, вам нужно поддерживать нескольконезависимые базы данных и т. д.

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

При проектировании схемы важно подумать о ключе шарда , который будет использоваться для определения, какой шард отвечает за документ.Это может зависеть от ваших моделей трафика.Предположим, у вас есть пользователь, который управляет ярмаркой.Раз в год его веб-сайт просто сходит с ума, но 360 дней - это один из сайтов с низким трафиком.Теперь, если вы осколите свой CustomerId, этот конкретный пользователь может привести к проблемам.С другой стороны, если вы используете шард на VisitorId, вам нужно будет нажать на каждый шард для простого count().

. Часть анализа во многом зависит от запросов, которые вы хотите поддерживать.Реальная сделка slice & dice довольно сложна, я бы сказал, особенно если вы хотите поддерживать аналитику практически в реальном времени.Гораздо более простой подход состоит в том, чтобы ограничить возможности пользователя и предоставить только небольшой набор операций.Они также могут быть кэшированы, так что вам не придется каждый раз выполнять все агрегации.

В целом, аналитика может быть сложной, потому что есть много функций, которые требуют отношений.Например, когортный анализ потребует от вас рассмотрения только тех записей журнала, которые были созданы определенной группой пользователей.Запрос $in подойдет для небольших групп, но если мы говорим о десятках тысяч пользователей, он не подойдет.Вы можете выбрать только случайное подмножество пользователей, потому что это должно быть статистически достаточно, но, конечно, это зависит от ваших конкретных требований.

Для анализа больших объемов данных удобно использовать Map / Reduce:будет выполнять обработку на сервере, а Map / Reduce также извлекает выгоду из шардинга, поскольку задания могут обрабатываться индивидуально каждым шардом.Однако, в зависимости от множества факторов, эти работы могут занять некоторое время.

Я полагаю, что в блоге Boxed Ice есть некоторая информация об этом;у них определенно есть опыт обработки большого количества аналитических данных с использованием MongoDB.