Программирование счётчиков статистики посещаемости

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

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

S_Flash писал:

Например, Счётчик с почасовой и ежедневной статой, где почасовая стата как бы интрполируется и на диаграмме не будет скачков в начале часа (то же самое для дней месяца).

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

Stek писал:

Сгруппировал данные в нужном правиле за час

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

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

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

S_Flash писал:

+ Лог - это ассоциируется сразу с неким файлом на диске. Это прям мовитон, какой-то! В современном мире есть же редис.

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

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

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

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