Архитектура Google Analytics или что нужно чтоб обрабатывать 500 запросов в секунду?

[Romantik]

Архитектура Google Analytics или что нужно чтоб обрабатывать 500 запросов в секунду?

Приветствую, уважаемые.

Хотел бы обсудить с Вами структуру подобие google Analytics

понятно, будет CLIENT side, это сайты, где будет размещен код счетчика
и USER side для просмотра статистики.

На USER side будет PHP и для вывода графиков Flash+ XML

В качестве сервера для приема CLIENT запросов думаю использовать
Amazon S3
и в качестве хранилища использовать HADOOP MapReduce

там же для увеличения скорости USER части в кроне
формируются XML файлы для "длинных отчетов во времени" (неделя, месяц, год)
и в USER интерфейсе flash будет брать нужные XML прямо с Amazon.
Для отчетов текущего времени использовать MySQL кластер.

понятно, что использовать HADOOP для этого- это "как из пушки по воробьям", но
ожидаемая нагрузка до 500! запросов в секунду.
(да... 1,8 млн. в час)

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

С уважением.

 

[Falc]

В свое время писал что-то подобное.
Реализация была следующая: на странице устанавливался счетчик ссылающийся на прозрачный однопиксельный гиф. Веб-сервер (nginx) отдавал картинку, писал запрос в лог, выдавал уникальную куку пользователю.
Лог писался таким образом что бы его можно было подгрузить в мускуль через "LOAD DATA INFILE INTO TABLE".
По крону запускался ПХП скрипт, который создавал временную таблицу, загружал в нее логи, и запускал мускульную процедуру, которая раскидывала логи уже по структуре базы.

Вобщем-то подобная схема может обрабатывать гораздо больше чем 500 реквестов в секунду. Основная тут проблема это реализовать структуру данных которая будет приемлемого размера и из которой можно будет формировать нужные отчеты за приемлемое время.

 

[Romantik]

Falc
идея хороша писать в лог, спасибо большое! =)

 

[Falc]

Romantik
Тут основная идея в том, что при обработки запроса пользователя не требуется запуск дополнительных обработчиков, все делает сам веб-сервер.
На моем домашнем компьютере бенчмак показал, что реально обработать больше 2000 запросов в секунду.

 

[voituk]

Falc
Реализуем аналогично, только пишем в стандартном формате, а потом парсим.

 

[si]

S3 - это storage, каком боком он тут вообще ? mysql ndb кластер очень специфичная штука и область его применения весьма ограниченная. 500 Req/sec вообще не много в нынешнем мире, учитывая наличие на рынке железа с 8 CPU (2xQuard Core) за вполне небольшие деньги.

 

[Romantik]

S3 и будет хранилищем всех логов (врменным), из которых и будут формировать XML (постоянным), которые будут там же.

в частности планирую готовые отчеты (к примеру за неделю) по крону сохранять (в них изменений уже не будет и расчет не нужен) и подобие кеша: если USER выбрал специфический отчет- сформировать и сохранить его.

MySQL получается промежуточным звеном и хранилищем данных.

 

[voituk]

в частности планирую готовые отчеты (к примеру за неделю) по крону сохранять

Тебе нужно сохранять не отчеты, а аггрегированые данные в таком виде, чтоб из него просто было построить отчет за любой срок (но в ущерб детальности)

-~{}~ 15.08.07 18:11:

IMHO S3 тебе тут вообще не нужен:
Получил данные, загнал в MYSQL, обработал, аггрегировал в во всех потенциальных разрезах, лог удалил, операцинные данные (те что 1запись=1запрос ) хранишь за день/месяц/неделю

 

[Romantik]

а смысл потом скриптом брать эти данные и формировать массив или тот же XML для графика?

в USER части будет вызываться flash график (Fusion Charts скорее всего), а он напрямую может работать с XML.

эта идея имеет недостаток такой, как количество мелких файлов, но по сути это статичные данные уже

 

[si]

зачем тут S3 ? зачем платить за него деньги елси сервер так и так у вас будет свой ?

 

[voituk]

Смысл скриптом брать эти данные - это возможность параметризации отчета.
Например если пользователь захочет количество уникальных посетителей в период с 08.07.2007 по 23.08.2007
(а такая возможность есть Google Analytics)
Каким образом ты будешь по XML-файликам собирать эти данные?

-~{}~ 15.08.07 19:06:

si
IMHO неплохой storage, но не с Украинскими ценами за иностранный трафик
Если уже его использовать то только вместе с Amazon EC2
Но согласен, что тут он не нужен.

 

[Kashey]

У меня сейчас такая система работает.
Запросы от клиентов добавляются в HEAP базу мускула в сжатом виде( те IP->long,подчистить урлы и тд)
Раз в 5 минут запускается крон на переброс "этого" в главную базу.
Раз в час запускается крон по выборки из главной базы часовой статистики.
Ну и раз в 4 часа - дневной.

Синтетические тесты на ноутбуке сел 1.5 полностью обработали 15М запросов за виртуальные 4 месяца за 60 секунд.
те 6 серий по 10 сек что я скрипту на работу выдавал.
Самое долгое было создание часовой статистики( группировка по сайтам\агентам). те каждая группа - свой if и свой инсерт..

 

[Sherman]

Автор оригинала: Falc
В свое время писал что-то подобное.
Реализация была следующая: на странице устанавливался счетчик ссылающийся на прозрачный однопиксельный гиф. Веб-сервер (nginx) отдавал картинку, писал запрос в лог, выдавал уникальную куку пользователю.
Лог писался таким образом что бы его можно было подгрузить в мускуль через "LOAD DATA INFILE INTO TABLE".
По крону запускался ПХП скрипт, который создавал временную таблицу, загружал в нее логи, и запускал мускульную процедуру, которая раскидывала логи уже по структуре базы.

Вобщем-то подобная схема может обрабатывать гораздо больше чем 500 реквестов в секунду. Основная тут проблема это реализовать структуру данных которая будет приемлемого размера и из которой можно будет формировать нужные отчеты за приемлемое время.

Сейчас решаем подобную задачу. Уперлись в то, как можно отдать куки, и при этом продолжить выполнение запроса (в nginx).

То есть схема:

php-fast-cgi process (log) отдает:

headers:
cookie
501

в nginx стоит директива error_page 501, которая отправляет запрос далее (в конце показывается картинка).
Но вот куки дальше не пробрасываются :-( Как обошли это вы ?

p.s. модуль для nginx уже писали, поэтому этот вариант не рассматриваем

 

[Falc]

А не как не решал. Всю работу делал nginx он умеет ставить пользовательскую куку, так что никаких php-скриптов не вызывается.

 

[Sherman]

Если вы про модуль userid то да, умеет, но вот нам надо чтобы это был hash sha1.