Счетчик: подсчет уникальных за период

[trigger]

Почему это другая? В остальных таблицах есть и готовая статистика/аудитория/статистика по страницам и прочая хрень.

"что касается аудитории рунета,"
Спасибо за инфу.

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

 

[Falc]

trigger
>>счетчик пишет лог в файл, демон читает и кидает в БД лог, потом дохрена демонов раскидывают по остальным таблицам.

С чем связано, то что счетчик сразу не пишет в базу? Насколько я понимаю если лог сразу писать в базу будет проще.
И еще вопросец: идентифицируете ли вы пользователей по кукам, если да, то какой индентификатор пишите в куку при первом заходе, насколько я понял счетчик с базой не работает, поэтому писать auto_inctiment поле в куку не удастца и придется генерить 128 битное уникальное цисло, а это менее удобно.

 

[trigger]

2Falc
"С чем связано, то что счетчик сразу не пишет в базу?"

C тем, что если базе немного полетать/постоять захочется, не придется извинятся перед клиентами, мол, мы проворонили Ваших посетителей с тогда-то по тогда-то.

"идентифицируете ли вы пользователей по кукам"

Точно не знаю, я писал только системы отчетов, но думаю, что да. Мне кажется, что даже "генерить 128 битное уникальное цисло" более удобно, чем брать некие хеши от всяких данных пользователя. На крайняк (мне тока што пришла идея) база может держать в отдельном файле|php-инклюде немного свободных id-шников.

 

[Falc]

trigger
Еще пару вопросиков если можно:
Сколько хитов в день вы обрабатываете сейчас и сколько собираетесь обрабатывать при удачном исходе?

Храните ли вы всю информацию в базе (о каждом хите) или только сводные данные?

 

[trigger]

Falc
Ух, ну и вопросики у вас... Мне самому стало интересно. Только что полазил по моей локальной БД: по самому open.by идет примерно запрос в 5 секунд(12:59-17:57), а он стоит на первом месте по посещаемости. Всего сейчас ресурсов примерно 6000. Потом может еще добавится... пускай 4000. Получается 2000 хитов в секунду. Да, храним таблицу логов(раздельно для каждого ресурса). Длина строки 283 "чистых байта". Возьмем 300 (если я правильно оценил объем служебной инфы).
Выходит... []= 2 гига в час.... 1.3 тера в месяц... Это ж им придется платить 1000$ на веник ежемесячно. Надо будет спросить.

Хотя если судить не по максимальным данным, то выходит даже ничего. Но все равно спрошу.

ЗЫ: Не подскажешь, что дольше работает: открытие файла или pconnect()? Это к твоему вопросу почему счетчик не работает напрямую с базой. Я не засекал.

 

[Falc]

trigger
Открытие файла конечно быстрее, но я думаю что не это будет узким местом.

2 гига в час это очень круто, ты видать что-то перепутал. С такой скоростью на диск писать не успеешь

 

[trigger]

Посчитаю снова: 3600*10000*0.2*283/(1024*1024)=
~1943.2
3600 -- секунд в час.
10000 -- сайтов логгируется.
0.2 -- запросов в секунду.
283 -- размер записи в байтах
Если убрать referer и user_agent, то получится 350 мегов в час(или снизить частоту запросов). Вот это уже реально.

Все равно, я думаю подвести итог этого топика: в рунете невозможно логгить посещения. В чем, в принципе, никто и не сомневался. [=

 

[Falc]

trigger
>>0.2 -- запросов в секунду.
Такая посещаемость далеко не у всех сайтов.

>>Все равно, я думаю подвести итог этого топика: в рунете невозможно логгить посещения. В чем, в принципе, никто и не сомневался.

Об этом я говорил еще в начале топика.
Т.е. вы не ведете полных логов для всех сайтов, а только временные так?

 

[trigger]

Об этом я говорил еще в начале топика.

Ну да. Тока я думал подвести итог, показывая цифры.

Т.е. вы не ведете полных логов для всех сайтов, а только временные так?.

Я по моему 2 раза сказал: храним. Храним долго. Наверно саму таблицу лога будут подчищать снизу ( вебмастеры хорошо посещаемых ресурсов уже будут знать наизусть всякие изощренные отчеты, в которых будет нужен лог)

 

[Falc]

trigger
>>А я по моему 2 раза сказал: храним. Храним долго.

Так погоди, ты сказал что у вас уже сейчас 6000 сайтов, если провести товоиже рассуждения:

>>3600 -- секунд в час.
>>10000 -- сайтов логгируется.
>>0.2 -- запросов в секунду.
>>283 -- размер записи в байтах
>>то получится 350 мегов в час

То на 6000 сайтах получится почти 200мегов в час. Это ж 120 гигов в месяц получится, это что каждый месяц вы в комп новый винт вставляете? И потом как вы с такой базой работаете? бекапыт там всякие, проверки?

 

[trigger]

Отвечу твоей же цитатой:

>>0.2 -- запросов в секунду.
Такая посещаемость далеко не у всех сайтов.

и моей:

Хотя если судить не по максимальным данным, то выходит даже ничего.

PS: Ты там, наверное, празднуешь свою тысячную мессагу?

 

[Falc]

trigger
Ясно, просто все равно много получается.

 

[Vinny]

Ребята, вы что, сбрендили??? 2000 запросов в секунду??? Это в сутки получается больше 170 лимонов... Ни один топ рунета столько не делает... Чтобы держать 2000 запросов в секунду вам нужен минимум 4-процессорный Xeon c раидом на сказевниках...

 

[Demiurg]

Vinny
Я же говорил, что на spylog только база крутиться на десятке машин (непроверенные данные)

 

[Vinny]

Demiurg
Помнится я кому-то сказал так же, про 10 машин... Но мне пояснили что на самом деле у спайлога база крутится на одной машине... Уже и не помню кто рассказывал...

И еще, про 2000 в секунду... Сегодня на:

spylog.ru: 80 401 693
top.mail.ru: 80 040 288
top100.rambler.ru: 112 555 806
hotlog.ru: 2 200 862

Так что 170 лимонов для белоруссии несколько многовато...

 

[n0b0dy]

Для начала, если ты собрался заниматься такой статистикой, тогда начнем. Вот сервера hotlog.ru
m6.mtu.ru
m8.mtu.ru
ank.ru
m4.mtu.ru
62.118.248.74
62.118.248.82
62.118.248.78
62.118.248.84
62.118.248.81
194.8.167.244
62.118.248.81
62.118.248.72
это только на первый взгляд. Да-да именно эти сервера занимаются обработкой статистики. И я просто уверен что эти сервера достаточно мощные и с очень большим количеством жестких дисков. И будь уверен что там вся инфа храниться не доброй «муське», а в БД что то вроде Оракл, «муська» как бы ео не расхваливали, ну не справиться он с таким большим количеством инфы.

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

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

Извените за оффтоп.

 

[n0b0dy]

Еще раз оффтоп

Пока копался с hotlog нашел достаточно интересные вещи
вот одна к примеру
62.118.248.72 посмотри внимательно за какое число там новости и в самом низу на дату (c) а потом сравни с существующем.

 

[Vinny]

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

В моем счетчике вообще нет ни одного JOIN-а... Пока моделька написана на php и на целеке 1.7 логается где-то по 200-300 запросов в секунду, а статистика разбирается со скоростью порядка 100-150 в секунду... Это на php, а будет написан демон на C...

И еще про оракл... Лицензия стоит порядка 30.000$ на процессор, несколько дорогова-то...

 

[Demiurg]

n0b0dy
зачем там оракл ? это все равно, что кирпичи на лимузинах возить.

 

[Falc]

Vinny
>>Серверов вполне может быть много, а база данных одна...
база данных то одна ностоит на нескольких серверах.
У спайлога кстати все на мускульке, так как для логов мускула вполне хватает.

>>В моем счетчике вообще нет ни одного JOIN-а...
В том-то и дело что у тебя счетчик, для счетчика достаточно таблицы site_id | count. А у нас уже пошел разговор о Системах сбора статистики, а в таких системах база состоит из десятков таблиц и в запросах к ним кучи JOIN'ов. Мускул кстати соединяет таблицы очень быстро.