@mediadata

Какую архитектуру выбрать для системы учета кликов?

Перед нами стоит задача создания распределенного трекера для учета кликов, который будет использоваться для пост-анализа рекламных кампаний (ppc).

Сложность в том, что рекламные кампании проводятся по всему миру, поэтому в системе необходимо иметь несколько серверов наиболее близких к конечному пользователю для исключения лишних потерь. При этом все клики должны скапливаться в единое хранилище, с которым будет работать система аналитики. Максимальная нагрузка на каждой локации - 1-2 миллиона кликов в сутки.

Пока мы абстрактно представляем себе такой вариант - в каждой локации размещается средний по производительности сервер, его задача сводится только к тому, чтобы обработать клик (простейшие правила на основании IP и User Agent-а) , сохранить его данные и передать их "выше". Также необходим мощный сервер, который призван агрегировать данные и на котором будет размещаться сама система аналитики и хранилище.

Быстродействие "принимающих" серверов очень критично, а сервер-агрегатор будет использоваться лишь для выборок и маркетинговой аналитики, поэтому его быстродействие не в первом приоритете.

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

Решение только для внутреннего использования.

Все огромное спасибо за идеи
  • Вопрос задан
  • 169 просмотров
Пригласить эксперта
Ответы на вопрос 1
@ZurgInq
На принимающих серверах - nginx. Прямо из него кладём данные в in-memory DB или в очередь используя встроенный lua или javascript (в последней версии nginx). Либо nginx передаёт данные дальше на бэкэнд, в роли которого может выступать что то очень быстрое, вроде eventmachine на ruby, аналоги из python или php, языки nodejs, go. Для БД можно использовать redis, либо если оперативы мало, а данных много, можно mongodb, из которой потом выбирать данные и отправлять в очередь.
Для очередей можно взять что то из RabbitMQ, apache kafka, beanstalk и другие.
На агрегирующих серверах Hadoop или другие модные слова.
Ответ написан
Комментировать
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы