Каунтер .. не детский =)

[Nime]

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

даёшь сорс

кстати, а у тебя это где? линк можно?

 

[clevel]

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

 

[Alex-AKF]

2clevel:
Сколько сколько тысяч в секунду?
А каким образом выявил эту вожделенную цыфру?

 

[clevel]

2clevel:
Сколько сколько тысяч в секунду?
А каким образом выявил эту вожделенную цыфру?

сколько максимально можно разпарсить записанных запросов в статистику за секунду...

 

[Tronyх]

Это я уже писал, но из-за проблем с сервером месага не сохранилась.

Как лучше хранить статистику, так чтобы она весела как можно меньше и по ней можно было как можно быстрее создавать отчёты... и конечно малой кровью
Вот мои мысли по снижению размера записи:
1. ip в int, вообще это надо делать всегда.
2. обрубать "http://" и "www."
3. браузер, ОС... вобщем все поля, где это возможно и оправдано хранить не "готовые" данные, а цифру-ссылку (1,2,...,n) которая при показе отчёта будет заменена соответствующим значением.
Но это так "семечки", боольше интересует вопрос о том как бы сделать группировку статистики по какому-нибудь интервалу времени, например час или день. Тогда например число хитов/хостов/... будет хранится не ввиде один_хит=одна_запись в БД, а одна_запись на определённый период времени в которой хранится число хитов/хостов за этот период времени. Но опять же всё сгрупировать не получается (как в таком случае сделать отчёт "ссылающиеся страницы" или "пути по сайту"?).
И что из себя должна представлять уже обработаная статистика?

 

[clevel]

есть логи, а есть сводные результаты статистики, не путай эти понятия. Это во-первых. Далее - я храню в файлах лог, но для новых пользователей - ос, браузер, номер куки - в мускуле таблица. Почему? проблема с пробелами в названии ОС - (я храню как варчар - в файле геморно парсить), насчет хранения цифирки - не знаю, много ютих браузеров стандартных + качалки всякие и т.д. (врое поисковиков), так что циферками не обойдешься....

 

[Tronyх]

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

Ещё как обойдёшся, тем более что этот список будешь создавать/обновлять не ты, а скрипт когда он "увидит" новый браузер. И весить это всё будет меньше.

 

[LamerOnLine]

Глупый вопрос от новичка......
А если писать в базу блоками по 100 записей олегче не стане ?
Или просто писпать в базу когда проц простаивает, т.е. нет сильной активности......

Или это чем-то не устраивает....
т.е. насколько важно в реал-тиме в бызу это сгонять ?

 

[Tronyх]

Или просто писпать в базу когда проц простаивает, т.е. нет сильной активности......

А где записи будут хранится пока не будет "малой нагрузки"? В файле? Тогда нужно делать блокировку, а это тоже время жрёт...
Не выдумывай, HEAP + INSERT DELAYED вполне достаточно.

 

[LamerOnLine]

Tronyх именно в памяти и будут ) ее родимую через семофор и будем блокировать.... быстрее семафора ничего сблокировать не удасться... а при правильном построении даты сегмент будет блокироваться на время обновления/добавоения даты и не более того.... на самом деле надо делать параллельный таск с низким приоритетом он и будет складывать данные в базу.... ) ВОТ.....
Да если память кончиться, точнее кончиться определенная для этой даты память надо просто поднять приоритет такска иди запустить более шустрый таск........ ))) точнее при добавлении новой записи делаем слип 5-10 сек..... правильно расчитав приоритеты слип будет наступать не более чем 1 раз в несколько часов...

 

[Nime]

А чем это лучше INSERT DELAYED?

 

[LamerOnLine]

Nime черт его знает, честно говоря... просто кто знает как работает это самы INSERT DELAYED.... т.е. то как он оптимизирован нам не известно..... а тут мы сами с усами..... просто я как вариант предложил.... спрашивали то что делать ? так вот один из вариантов.

 

[Tronyх]

просто кто знает как работает это самы INSERT DELAYED....

Ну я знаю
Если у тебя в программе INSERT без флага DELAYED то твоя программа будет ждать пока не выполнится этот запрос, а если есть флаг то твой запрос помещается в очередь, следовательно программа не "подвисает".

 

[LamerOnLine]

Tronyх это понятно, но каков механизм этой записи и насколько он реально правильно распределит нагрузки ?
Я же говорю о блочной записи, и ступоре только по действительному исчерпанию ресурсов... )

 

[Tronyх]

Думаю с DELAYED MySQL распределит нагрузку гораздо лучше(ведь очередь состовляет сама БД), чем твои 100 запросов подряд.

 

[LamerOnLine]

Tronyх спорить не буду надо проверять )

 

[aloner]

Повторяюсь.

Berkley DB!

Realtime-данные пихать в нее, а потом уже перетягивать не торопясь в SQL-базу.
Преимущества описывать не буду: http://www.sleepycat.com/products/concurrent.shtml.

Собственно, MySQL в транзакционном варианте ее и использует, как backend для хранения данных.