-
Здравствуйте!
Есть задача написать внутреннюю статистику для сайта. Учитывать количество просмотров новостей, блогов, профиля пользователя, кол-во записей в блогах, комментариев и т.д.
С развитием статистики, количество параметров будет расти (без фанатизма).
Скорее всего это будут денормализованные поля. Где лучше хранить поля: в той же таблице или создать отдельную? Как сделать так чтобы сбор статистики не убил производительность?
Как я понимаю, есть 2 подхода к сбору статистики: 1) пишем лог событий во временную таблицу, по крону ее разбираем, считаем нужные параметры. 2) собираем данные напрямую в реальном времени.
Мне больше нравится второй вариант, но как не заблудиться в таком кол-ве параметров?
Буду рад любым идеям.
Спасибо -
Меня сейчас, конечно, закидают помидорами, но самая точная (НМВЗ, конечно) статистика - это access.log :)
Я бы статистику делал именно на основе его парсинга. Простой и не очень оптимизированный перловый скрипт парсит гигабайтные логи в считанные минуты. А ведь если они (логи) ротируются, то те жэе гигабайты будут на весьма и весьма загруженных проектах.
(обновлено) Я невнимательный человек, оказывается. Про количество записей\блогов и комментариев не дочитал. Посыпаю голову пеплом :( -
Мне кажется, что временная таблица здесь ни к чему.
Нужна одна таблица, в которой будут храниться данные со столбцами:
тип-параметр (количество блогов, например) - значение - датаивремя.
Из такой таблицы можно будет, кстати, рисовать диаграммы с ростом данных во времени.
А формировать таблицу, наверно, по крону. Хоть раз в минуту.
Тут ведь запросы простые должны быть.
Причем для каждого параметра будет своя функция, ну и пусть.
И добавлять в будущем таких параметров можете сколько угодно. -
Скорее всего это будут денормализованные поля.
Это нормальный вариант, но это также и хрестоматийный пример на RC. Соответственно, нужно будет мудрить со всякими блокировками и транзакциями. Это не страшно, просто об этом стоит помнить. Как это скажется на производительности - зависит от конкретной бд.
пишем лог событий во временную таблицу, по крону ее разбираем, считаем нужные параметры.
Это намного быстрее. разбирать можно даже не по крону, а по обращению за статистическими данными. Конечно, это вариант для рабочей статистики, когда обращения за данными происходят намного реже считаемых событий. Если же статистика дёргается на каждой странице (счётчик-пузомерка), то выигрыш теряется.
-
Anonymous22.10.2009
0
0
-
@Anonymous: sanestat не подходит. Мне нужна статистика, больше нацеленная на подсчет внутренних объектов, чем просто посещений и парсинга логов.
-
Всё зависит от того, что именно надо ..
Меня всегда устраивала гугловская статистика, разумеется, по объективным причинам, она не может посчитать некоторые вещи.
Собственно, что именно вам в ней не хватает? Количество объектов на сайте можно собирать и кэшировать в какой-нибудь таблице скриптом по крону. Или собирать в режиме реального времени - в зависимости от того, как часто вы смотрите статистику и за какое время она вам нужна. Согласитесь, если в базе данных много записей и вы будете их дергать для создания отчетов всякий раз - это вызовет большую нагрузку на сервер. Логичнее скриптом из крона ночью обновлять. Разумеется, если вам нужна оперативная информация за последние 15 минут и вы весь день планируете следить за каким-то показателем, то так не получится..
Если вы планируете сравнивать статистику чего-либо за разные временные интервалы и делать какие-нибудь интересные сложные запросы - сразу подумайте о внедрении простенькой OLAP.
Например, есть Palo http://www.jedox.com/en/home/video.html или
Pentaho Analysis Services: Mondrian Project + Pentaho Reporting
Например, если вы владелец хабра и внедрите эту систему, она позволит вам получать красивые отчёты (включая диаграммы, графики), скажем, как сильно изменяется карма у женщин по ночам за период с 11 января 2005 по 16 июля 2009 года, которые состоят в друзьях у Васи Путечкина и имеют как минимум 100 комментариев по сравнению с мужчинами (за тот же период и с теми же условиями отбора). А потом, сравните с другим периодом, или, скажем сравните показатели по разным месяцам между собой...
Вообщем, можно выдернуть абсолютно любую статистику по вашей базе. Ограничение тут пожалуй только такое: 1 поле - 1 значение (есть всякие ETL, чтобы получить данные в нужном виде и прочее, но это лишние заморочки, проще джангу заставить продублировать в нужном виде в отдельную связанную таблицу, к которой вы потом будете обращаться для получения данных для генерации отчетов/анализа). -
То есть как бы три уровня:
1. access.log
2. google
3. отчёты на основе ваших запросов к таблицам БД
3 уровень занимается только тем, что не могут первые два -
которые состоят в друзьях у Васи Путечкина
Ой, как бы политику не припаяли...
Извините:-)
Внимание! Это довольно старый топик, посты в него не попадут в новые, и их никто не увидит. Пишите пост, если хотите просто дополнить топик, а чтобы задать новый вопрос — начните новый.