Новая тема   Ответить

 S_Flash
Подкинте статеек, где рассматриваются основные приёмы написания счётчиков посещаемости.
Интересуют в первую очередь всякого рода оптимизации и "плавное представление данных". Например, Счётчик с почасовой и ежедневной статой, где почасовая стата как бы интрполируется и на диаграмме не будет скачков в начале часа (то же самое для дней месяца).

 Stek
Пишешь данные в лог файл, а потом уже обрабатываешь его как тебе заблагорассудится.

S_Flash писал:
Сгруппировал данные в нужном правиле за час и скормил любой js библиотеки построения графиков - будет тебе плавный график нарисован.

 S_Flash
Stek писал:
В это м и вопрос. Как оптимально хранить и группировать данные. Например, есть методы хранить данные в кеше, создавая почасовые ключи и потом их будет удобно сглаживать суммируя в нужном диапазоне для плавной статы (то же самое по дням). А ещё дело "усложнится", если в стату включить выборку по странам, уник-неуник и мелочи вроде реферов и юзер-агентов.
Ламерский полход в лоб любому начинающему программисту ясен, но я уже прозрел, как делают с обыкновенными счётчиками, поэтому считаю, что есть и общеизвестные методы.
JS библиотеки - это самое очевидное и простое.
+ Лог - это ассоциируется сразу с неким файлом на диске. Это прям мовитон, какой-то! В современном мире есть же редис.

 Sterx
любое кей-вэлью хранилище
привязываешь по ключу счетчик - грубо сам ключ набор слов
useragent_country_hits
partreferer_raws

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

 Stek
S_Flash писал:
Запись в лог файл ограничена только твоим диском. Затрат ресурсов нет, скорости огромные, при условии записи в append режиме. А редис надо держать отдельным сервисом, открывать к нему соединение, он будет жрать память. Имхо разницы в скорости не будет ни какой, может даже файл и выиграет

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

Можно еще вот тут посмотреть, что бы прикинуть, в какую сторону двигаться.

Имхо тут три пути:
1. изобретать велосипед чисто под себя
2. изучать Hadoop и подобное для обработки биг-дата. Но х.з. как это делать самому, без консультаций от знающих людей, которых хрен найдешь.
3. забить и использовать готовые решения