Есть система интернет магазинов с партнеркой. Каждый просмотр и покупка товара логируется. Ожидается до нескольких миллионов записей в базу в день. Нужен готовый скрипт статистики. Подсчет просмотров, покупок. Статистика и графики pа год по месяцам, за месяц по дням, за день по часам + GeoIP(статистика по странам). + красивые графики + расширенные фильтры. Скрипт должен регулярно обсчитывать статистику не кладя при этом базу данных и сервер )) Что делать? Искать готовый бесплатный? Покупать платный? Кто что юзает? Писать самому всё равно что писать CMS = изобретать велосипед.
Administrator Написать абы как каждый может и что угодно. Написать хорошо, удобно и эффективно работающее - единицы из тысячи. И только те, кто имеет опыт реализации нагруженных систем. К тому-же тут задача специфичная и под конкретное строение базы. Да и сама организация базы тут требует больших усилий и понимания тонких моментов не только базы, но и железок.
Вот и хочется взять готовый. Форумы неплохие готовые - есть. CMS -море. Есть и неплохие. Даже операционные системы опенсорсные есть. Почему бы и скрипт статистики не найти более-менее вменяемый...
Специфичное у вас заданиьице, все же. Я вот под свои миллионы записей в день уже третий день сервер настраиваю ) При том, что за Oracle мы заплатили честные деньги И имеем техподдержку. Но специфичные случаи - они всегда такие.
Советую искать в интернете готовое решение с хорошо реализованным API. Потратив на ознакомление готовых счетчиков несколько дней можно реально сэкономить во времени. Случается, что качество от цены никак не зависит. Есть много готовых бесплатных решений на которые смотреть страшно, есть красивые решения, есть платные и ужасные... Тут скорее всего следует руководствоваться качеством инструкции (мануала) и легкостью интеграции в свой проект. Обычно если эти два критерия удовлетворяют, то и сам продукт "приходится по душе".
Возьмем для примера этот, скажем не самый посещаемый сайт. В шапке на главной странице написано: "За последние 24 часа нас посетил 2341 программист " Итак: 2500 челоек в день. Если каждый откроет 10 страничек мы получим 25 000 записей в статистике. Если в системе 20 подобных сайтов то получится полмиллиона логов в день. Вроде не запредельные нагрузки. Есть сайты где посещения меряюбтся сотнями тысяч в день и больше.
как все запущено.... вы путаете счетчик посещений и лог событий с уникальными х-ками каждого события.
topas, Она будет хорошо документирована на языке php. ) Согласен. Первое обычно считается путем анализа запросов к странице, и фактически, нагрузку на себе несет вебсервер, банально обслуживая запросы. В вашем случае все гораздо сложнее, ибо вовлекаются куда более сложные абстракции - чем запрос документа с сервера.
В любом случае API и примеры использования должны быть описаны... Иначе можно столкнутся с высоким входным порогом использования такой программы. Обычно, системы без документации понятны только автору
topas Горбунов Олег правильно говорит. Просто счётчик посещений/действий это легко. А вот когда нужен довольно основательный лог и потом его анализ - вот где будут проблемы, особенно при больших объёмах. И всё дело даже не тупо в сборе статистики (благо просто INSERT дописывает в конец таблицы и с этим особых проблем нету) - проблемы начинаются при обработке данных, в эти моменты сервер базы данных может просто сдохнуть. Тут вся сложность именно в базе, а написать интерфейс к статистике это уже намного проще (хотя есть свои заковырки, но не столь глобальные и идейно решаются довольно быстро, особенно если есть какой-никакой опыт в этом).
Да, я вот попробовал написать свой простой анализатор статистики. При миллионе записей в базе он у меня сдох
угу, была б у меня куча бабок, я бы это решил репликой на другой сервер, где бы денормализовал статистику по данным в таблички, и их уже отдавал. Может быть, частичную денормализацию данных еще на ходу бы делал.
Clone Вот поэтому такие решения стоят не дёшего (как код, так и железо) и пишутся в основном индивидуально под каждый проэкт, т.к. это не просто написания хорошего кода требует но ещё и хорошего планирования инфраструктуры серверов, поскольку одним сервером обойтись тяжело - надо хотя-бы 2-3. P.S. Мне уже даже стало интересно, я бы занялся этой штуковинной
Горбунов Олег не, это в любом случае надо чуть ли не ежедневно пересчитывать в отчетность по периодам, иначе сдохнет.
Горбунов Олег У меня есть даже более бешанная идея (и, кстати не такая уж дурная), для неё надо 2 сервера для начала и если это не google-analytics по объёмам, то вполне хватит на какое-то время. Репликация к моей идее вполне хороший вариант, а лучше бинарный лог и переодическая скачка его на другой сервер (что избавит базу от нагрузки, т.к. стянем тока фаил). А там уже все пересчёты и интерфейс.