Рекомендация для механизмов отслеживания щелчка/события (Python, django, сельдерей, монго и т.д.)
Я изучаю путь к беговым соревнованиям в django приложении (события обычно были бы щелчками, связанными с определенным уникальным идентификатором пользователя).
Эти события по существу содержали бы тип события как "щелчок", и затем каждое событие щелчка будет присвоено уникальному идентификатору (много событий могут перейти к одному идентификатору), и каждое событие имело бы набор данных включая объекты как ссылающийся домен и т.д...
Я попробовал mixpanel, но на данный момент API данных, который они предлагают, кажется слишком ограничивающим, поскольку я, может казаться, не нахожу способ вывести все мои данные уникальным идентификатором (кроме самого события).
Я изучаю использование django-eventracker, но любопытный на предмет любых других думал на лучшем способе сделать это. Монго или CouchDb походят на большой выбор здесь, но celery/rabbitmq выглядит действительно привлекательным с монго. Нагнетание этих событий в дб существующих приложений кажется ограничением в этой точке.
Так или иначе это - просто поток для наблюдения, какие мысли других находятся на этом и как они реализовали что-то вроде этого...
охота
3 ответа
Я не знаком с упомянутыми вами заранее готовыми решениями. Если бы я спроектировал это с нуля, у меня был бы простой JS, собирающий информацию о кликах и отправляющий ее обратно на сервер через Ajax (используя любую структуру JS, которую вы уже используете), а на стороне сервера я бы просто добавил эту информацию в файл журнала для последующей "автономной" обработки - так что, по сути, это не будет зависеть от django или другой серверной инфраструктуры.
Добавление к файлу журнала - очень легкое действие, в то время как базы данных для использования в Интернете обычно оптимизированы для операций с интенсивным чтением ( не с интенсивной записью), поэтому я согласен с вами, что принудительно размещение этой информации (поскольку она обманывается) в базе данных существующего приложения вряд ли обеспечит хорошую производительность.
Вы, вероятно, хотите сохранить гибкий формат для своих журналов, чтобы предвидеть будущие потребности или изменения. В этом смысле бессхемные документно-ориентированные базы данных хороши. Одним из преимуществ является то, что структура ваших данных будет близка к потребностям вашего приложения для любого анализа, который вы будете проводить позже (таким образом, вы избежите некоторых неизбежных работ по разбору/измельчению данных).
Если вы думаете об использовании mysql, postgresql или чего-то подобного, то вам стоит обратить внимание на что-то вроде rsyslog для буферизации записей и избежания снижения производительности при интенсивном протоколировании. (Я не могу много сказать о celery и других механизмах очередей для такого типа вещей, но они звучат многообещающе).
Mongodb имеет несколько хороших возможностей, которые делают его пригодным для логирования, например, capped collections. Краткое описание можно найти в этом посте.
Если под щелчком вы имеете в виду щелчок по ссылке, которая загружает новую страницу (или выполняет запрос AJAX), то ваша цель довольно проста. Веб-серверы, как правило, ведут журналы в виде обычного текста о запросах - с информацией о пользователе, времени / дате, реферере, запрошенной странице и т. Д. Вы можете изучить эти журналы и собрать необходимую статистику.
С другой стороны, если у вас есть веб-приложение, в котором клики не обязательно генерируют запросы к серверу, то сбор информации о кликах с помощью javascript - ваш лучший выбор.