Рекомендации по механизмам отслеживания кликов / событий (питон, джанго, сельдерей, монго и т. Д.) - PullRequest
7 голосов
/ 16 июля 2010

Я ищу способ отслеживать события в приложении django (события, как правило, представляют собой клики, привязанные к определенному уникальному идентификатору пользователя).

Эти события по существу содержат тип события, например «щелчок», и затем каждому событию щелчка присваивается уникальный идентификатор (многие события могут переходить к одному идентификатору), и каждое событие будет иметь набор данных, включая такие элементы, как реферер и т. Д. ..

Я пробовал mixpanel, но на данный момент API данных, которые они предлагают, кажется слишком ограниченным, так как я не могу найти способ вывести все свои данные с помощью уникального идентификатора (кроме самого события).

Я изучаю использование django-eventracker, но мне любопытно узнать, как другие думают, как сделать это лучше. Mongo или CouchDb кажутся отличным выбором здесь, но сельдерей / кролик выглядит действительно привлекательно с монго. Накачка этих событий в существующие приложения БД на данный момент кажется ограничивающей.

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

стрелять

Ответы [ 3 ]

3 голосов
/ 16 июля 2010

Я не знаком с упомянутыми выше пакетными решениями.Если бы я разрабатывал это с нуля, у меня был бы простой JS, собирающий информацию о щелчках и отправляющий ее обратно на сервер через Ajax (используя любую среду JS, которую вы уже используете), а на стороне сервера я бы просто добавилэта информация в файл журнала для последующей «автономной» обработки - так что, по сути, она не зависит от django или другой серверной среды.

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

2 голосов
/ 16 июля 2010

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

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

Mongodb имеет несколько приятных особенностей, которые делают его пригодным для регистрации, таких как ограниченные коллекции.Резюме можно найти в этом посте .

1 голос
/ 16 июля 2010

Если под кликом вы подразумеваете клик по ссылке, которая загружает новую страницу (или выполняет запрос AJAX), то то, что вы хотите сделать, довольно просто. Веб-серверы, как правило, хранят текстовые журналы о запросах - с информацией о пользователе, времени / дате, реферере, запрашиваемой странице и т. Д. Вы можете просмотреть эти журналы и получить необходимую статистику.

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

...