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

Vinny

Guest
Falc
В самом низу страницы написано:

Спомощью этого отчета Вы можете узнать сколько посетителей с уникальным IP-адресом посетили ваш ресурс в определенный отрезок времени.
 

Falc

Новичок
Vinny
Они не сволочи, просто такое кол-во информации хранить не возможно, а а выборка из нее сожрет все процессорное время для расчета статистики по не очень большому сайту.
 

Falc

Новичок
Vinny
>>Спомощью этого отчета Вы можете узнать сколько посетителей с уникальным IP-адресом посетили ваш ресурс в определенный отрезок времени.
Весьма расплывчатая формулировка, но все-таки можно сказать что они дурят народ :)
 

KillaBee

Guest
Я извиняюсь, что встреваю...
Я так понимаю, что хранить базу в примерно следующем формате уже считается не серьезно.

(фиксируется каждый хит пользователя)

время|ip|откуда_пришел|куда_пришел|...|... |...

откуда_пришел и куда_пришел хранятся в виде урлов

Или я что-то неправильно понимаю???
 

Demiurg

Guest
KillaBee
ты плохо читал топик.
представь, что случиться с базой при миллионе хитов в день.
 

KillaBee

Guest
Я хорошо читал... Поэтому и написал, что "это" уже не модно... :))
Кароче надо для каждой страницы айдишку заводить и уже далее ее использовать...

А как обработать синхронный доступ к логу?
 

Demiurg

Guest
про немодно я лично ничего не нашел. Мода тут не причем. То, что русскому хорошо, немцу - смерть.

>Кароче надо для каждой страницы айдишку заводить и уже далее ее использовать...
а чем "айдишка" будет отличаться от урла страницы ?

>А как обработать синхронный доступ к логу?
чего ?
 

KillaBee

Guest
Мы индексируем сайт... Каждой странице ставим в соответствие уникальный целочисленный код. Для этого дела заводим отдельную базенку, где храним пары url | id. Далее в логах будем хранить не запрашиваемые урлы, а их id. Это будет экономнее...

Про синхронный доступ не уверен, что задал корректный вопрос, но все-таки расшифрую.

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

Demiurg

Guest
>Это будет экономнее...
то есть ты хочешь сказать, что целочисленый индекс эффективней строкового ?

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

KillaBee

Guest
Originally posted by Demiurg
>Это будет экономнее...
то есть ты хочешь сказать, что целочисленый индекс эффективней строкового ?

А мы об одном и том же говорим? Я имею ввиду, что урл намного длиннее чем id и можно описать урлы сайта в одной базе по вышеизложенному принципу...

Пр

0|index.php
1|index.php?act=blablabla
2|board.php
...

Это на порядок экономнее, чем каждый раз писать запрашиваемые урл в лог... Или я не прав?

>Может получится так, что одновременно на запись в лог его
>откроют две копии скрипта, пока будет работать одна другая
>может что-нибудь записать, а потом, когда другая также
>запишет, мы потеряем предыдущую запись.
ты не поверишь, но базы данных разрабатывают так, что ба информация не терялась.
Издеваешься? Я в принципе так и думал... :)
 

Demiurg

Guest
>Это на порядок экономнее, чем каждый раз писать запрашиваемые урл в лог
обоснования где ?
 

KillaBee

Guest
Хмм...
Ну смотри допустим мы фиксируем каждый хит юзверя, в строке описывающей хит присутствует referer и query url,
к примеру если юзверь шастает по сайту то в запись будет иметь такой вид:

... | ... | ... | forum.******.ru/ | /?id=30 | ... | .... | ...

/*из личного лога :) */

Пусть
0 ~ forum.******.ru
...
128 ~ /?id=30

тогда запись примет такой вид:

... | ... | ... | 0 | 128 | ... | .... | ...

А если таких записей в день, как ты сказал 1Mb, то экономия на лицо...
 

Demiurg

Guest
Ты имеешь экономию места на диске ? винты сейчас дешовые, можешь посчитать сколько секономишь в год, если в день будешь экономить 2 Мб в лучшем случае $1? а лишняя таблица при этом будет присутсвовать, оптимизатор будет рассматривать её, при вставке новой замиси надо будет понять есть ли такая запись в то самой этой таблице, и только после этого мы поймем вставлять или нет в неё новую запись. И того имеем:
Значительное падение производительности при некотором выиграше в занимаемом дисковом пространстве в задаче с критическими требованиями по быстродействию.
 

KillaBee

Guest
Я тебя понял... По поводу доп. бызы - согласен. Доп. гемор... Я думаю выигрышь будет не 2мб, к тому же если счечик обслуживает тысячи сайтов... Ну это не важно... Мы же беседуем :)

Что же теперь вообще подробную статистику не вести? Или есть какой то выход, чтобы фиксировать все действия пользователя?

Я не очень пойму что-ты имел ввиду отвечая "представь, что будет с базой, если в день будет 1Мб хитов" на мой первый пост? А что с ней будет? Ну да она будет охренительно много весить? Или ты о другом говорил...?
 

Demiurg

Guest
дело даще не в размерах а в том, что если в таблице будет несколько миллионов записей, то для того, что бы апдейтить её надо апдейтить индексы, а это весьма не тревиальная задача. На счет того, что делать - уже сказали, не вести полную статистику, а записывать в базу статистические данные.
 

Vinny

Guest
KillaBee
Ну, ты америку не открыл... И ежу ясно что надо хранить идентификаторы...

Demiurg
Числовой индекс работает быстрее потому как сравнение чисел быстрее чем сравнение символов... Даже не так, числовой индекс будет занимать для данной задачи 4, максимум 8 байт, а в url страницы первые 4 байта - это "www."

Далее, не зря наверное мускульцы настоятельно рекомендуют начинать оптимизацию БД с уменьшения размерности полей...
 

trigger

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

Автор оригинала: Vinny
Вопрос к тем кто делал когда-либо счетчики...
Моя тема. Я работал (и работаю) с такой базой.

Во-первых: у нас есть таблица пользователей. Большая, не спорю. Даже очень. Идентифицирует не только по ip. У нас только белорусские сайты, модерация обязательна. Поэтому сайтов ~10 тысяч. Но не 100.

Во-вторых, скрипту счетчика лучше не работать с базой. У нас сделано так: счетчик пишет лог в файл, демон читает и кидает в БД лог, потом дохрена демонов раскидывают по остальным таблицам(countы, sumы итп). Эти уже скорее не демоны, а кроны. Заметь таблиц >20;

В-третьих: если тебе нужна статистика за произвольный промежуток времени, то я думаю, что кто-нить сможет тебе математически доказать, что одними сводными статистиками ты это не сделаешь. Разве что вероятностно. Тут уж сам думай. [=

PS: В работе эту красоту сейчас не посмотрите, тк запускаться система будет весной. Сейчас есть только старая система, где ничего этого нет.
 

Vinny

Guest
trigger
Спасибо за ответ.

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

Меня сейчас больше беспокоет потенциальный размер таблиц... Пока собираюсь для каждого из сайтов заводить отдельную таблицу со связкой (Site_Id, Host_Id) потому как потенциально хостов может быть несколько миллионов и, в худшем раскладе, это будет умножено на количество сайтов... Слишком много записей получается...

ЗЫ: А можно схему БД посмотреть?
 

trigger

Guest
"Меня сейчас больше беспокоет потенциальный размер таблиц..."
Размер таблиц сильно влияет на производительность только если ты делаешь по этим таблицам сложные SELECTы или делаешь запросы с обьединениями таблиц. А простые операции делаются быстро, log(кол-во записей). Если ты юзаешь индексы конечно.
И не извращенные типы таблиц.

"Пока собираюсь для каждого из сайтов заводить отдельную таблицу со связкой..."
Зачем? У нас так: таблицы логов (log_12345), в которых одно поле -- идентификатор пользователя.
Он же -- ссылка на таблицу юзеров. В таблице юзеров есть вся инфа о юзере( ip, язык, оська, вкл/выкл кукисов, итп).

Ты кста, проверь скока юзеров примерно в рунете. Мне тоже будет интересно.
В байнете (.by) конечно меньше, но в таблице считаются ведь не только белорусские пользователи. У меня в локальной таблице за несколько часов сбора статистики накопилось 42 страны. Таблица юзеров: не уверен, что за эти часы, скорее всего, что за более долгий период, но там 60 тысяч записей. Не так уж много.

Отчеты желательно формировать по одной таблице. Я имею ввиду, отчет "лог" выводит только то, что есть в таблице лога( ID посетителя, страна, ip.) нажав на посетителя -- увидим все его данные, какими ip пользовался из таблицы юзеров. Заметь, что данные столбцы "страна" и "ip" дублируются в логе и юзерах, чтобы не делать JOIN. Если нужны сложные отчеты -- например, рейтинг проходимых путей по сайту, тут тебе может помочь кеширование, хотя некоторые его и не любят.

"А можно схему БД посмотреть?"
Извини. Я уважаю труд project manager'а.
 

Vinny

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

Что касается аудитории рунета, то по хотлогу сегодня было обработано порядка 45 миллионов запросов, а это около 1-5 лимонов уников... На top.mail.ru 1,7 лимона уников... На top100.rambler.ru 67 лимонов запросов... Я конечно не расчитываю на такую аудиторию, но заложить возможность обработки такого количества пользователей стоит...

Что касается оптимизации, то при росте количества запросов будет и кеширование, и избыточность данных... пока этого не надо...

А у вас менеджер проектов проектирует базу? :) Ладно, не хочешь, не показывай...
 
Сверху