Комментарии 9
Любопытно, какая такая реальная необходимость заставила вас изобретать аналог Метрики и Google Analytics?
Нужно было: 1. не учитывать просмотры пользователем собственного объявления, 2. одновременно считать не только просмотры объявления, но и для автосалонов вести статистику по просмотрам их объявлений. Вот тут возникла основная сложность, т.к. при импорте объявлений от автосалонов, часто бывает, что одни объявления удаляются, а новые появляются. Как следствие, при удалении объявлений пропадает и статистика по ним, поэтому при увеличении счетчика просмотров объявлений мы инкрементим и счетчик просмотров у Автосалона. 3. по достижении определенного числа просмотров для автосалона производить некоторые триггерные действия (планировали производить биллинговые операции при достижении N просмотров).
Интересная тема. Но я бы сделал немного иначе.
На сколько я понял, задача заключается в том, чтобы «быстро» записывать статистику. Подобную вещь я бы сделал асинхронной, чтобы не тормозила вывод страницы, а просто складывалась в очередь (например, Gearman). Создал бы воркер, который записывает в БД нужные данные (время, user-agent, url и т.п.) о каждом посещении (в качестве БД я бы выбрал PG, хотя и задумался бы над выбором NoSQL решения).
Ещё можно распаралелить это дело. Для этого делаем master-master репликацию и поднимем на тех же серваках дополнительные воркеры для Gearman.
Задержка записи логов стала большой? Количество задач стало увеличиваться? Добавляем воркеров. Не помогло? Добавляем новый сервак.
На сколько я понял, задача заключается в том, чтобы «быстро» записывать статистику. Подобную вещь я бы сделал асинхронной, чтобы не тормозила вывод страницы, а просто складывалась в очередь (например, Gearman). Создал бы воркер, который записывает в БД нужные данные (время, user-agent, url и т.п.) о каждом посещении (в качестве БД я бы выбрал PG, хотя и задумался бы над выбором NoSQL решения).
Ещё можно распаралелить это дело. Для этого делаем master-master репликацию и поднимем на тех же серваках дополнительные воркеры для Gearman.
Задержка записи логов стала большой? Количество задач стало увеличиваться? Добавляем воркеров. Не помогло? Добавляем новый сервак.
Да, такой механизм бесспорно более мощный, но и более сложный и трудозатратный в реализации. У нас на реализацию и внедрение ушло дня 2 с учетом небольшого нагрузочного теста. И потом еще пара часов на доработки и изменения бизнесс логики. А вообще для более сложной и мощной системы учту Ваш метод.
Но это в случае, если надо обрабатывать ОЧЕНЬ большое количество запросов. Если справляется один сервак, то смысла городить подобную махину нет, согласен.
А вообще, чтобы поднять такое, не нужно много времени.
1) Установить и настроить Gearman (5 минут)
2) Написать воркеры для обработки задачи практически на любом языке. Не 5 минут, но тоже быстро.
3) Написать класс, который будет отсылать задачи гирмэну. Можно сохранить интерфейс класса, который записывает данные напрямую, сэкономим времени на интеграцию.
4) Вот настройка репликации может занять не мало времени (по крайней мере у меня). Хотя если нам хватает мощностей одного сервака, то делать этого не стоит.
И в итоге мы получим систему, которую без правки кода можно масштабировать.
Недавно изменял одну вещь на работе (шифровка/перешифровка большого объёма данных), сделал её асинхронной через воркеры на 2-х серваках. На реализацию, тестирование и доработку ушло меньше одного рабочего дня. И это при том, что в случае со статистикой нам не нужно писать чекер статусов (выполнился/в процессе/в очереди, на какой стадии находится), а в моём случае надо было. Да и небольшое нагрузочное тестирование я тоже сделал. Т.к. серваков у нас 2, то количество одновременно выполняемых запросов (собственно и скорость) возросло ровно в 2 раза, что, в принципе, было ожидаемо.
Так что по времени тут за 2 дня можно очень легко уложиться, если, конечно, хорошо представлять себе что мы делаем ;)
А вообще, чтобы поднять такое, не нужно много времени.
1) Установить и настроить Gearman (5 минут)
2) Написать воркеры для обработки задачи практически на любом языке. Не 5 минут, но тоже быстро.
3) Написать класс, который будет отсылать задачи гирмэну. Можно сохранить интерфейс класса, который записывает данные напрямую, сэкономим времени на интеграцию.
4) Вот настройка репликации может занять не мало времени (по крайней мере у меня). Хотя если нам хватает мощностей одного сервака, то делать этого не стоит.
И в итоге мы получим систему, которую без правки кода можно масштабировать.
Недавно изменял одну вещь на работе (шифровка/перешифровка большого объёма данных), сделал её асинхронной через воркеры на 2-х серваках. На реализацию, тестирование и доработку ушло меньше одного рабочего дня. И это при том, что в случае со статистикой нам не нужно писать чекер статусов (выполнился/в процессе/в очереди, на какой стадии находится), а в моём случае надо было. Да и небольшое нагрузочное тестирование я тоже сделал. Т.к. серваков у нас 2, то количество одновременно выполняемых запросов (собственно и скорость) возросло ровно в 2 раза, что, в принципе, было ожидаемо.
Так что по времени тут за 2 дня можно очень легко уложиться, если, конечно, хорошо представлять себе что мы делаем ;)
В итоге таблицу счетчиков обновляем не 100 раз (размер окна), а в среднем 7 раз.
Тогда уж стоило использовать Multiple Queries / Multiple Statement Execution.
В качестве окна можно использовать лог веб-сервера, это значительно уменьшит расходы на подсчет т.к. позволяет вообще не обращаться к бд при кэшировании страницы. Что касается таблицы в памяти, можно использовать буфферизированную запись лога (такая возможность есть например в nginx).
Если захотите опять поиграть с парсингом логов, может помочь моя утилитка, про которую я недавно написал пост. По крайней мере, при изменении формата урлов или логов не нужно будет лезть в исходники, все настраивается через конфигурацию. Правда, она заточена только под апач и совместимые логи.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Способы подсчета статистики посещения страниц сайта «на лету»