Ребёнка - хорошая идея ))
Реально, проверено на людях (на себе). Вот третий год идёт уже. :)
Ну правда доля интернета была не так велика, основное делается уже в реале.
Сначала записывал в базу айпишники как есть, в виде строки. На php считал простым перебором: доставал айпишник, сравнивал через strstr присутствует ли он в контрольной строке, если нет - добавлял его туда и увеличивал счётчик, если присутствует - дальше.
Время работы скрипта замеряю на одинаковом размере таблицы с айпишниками, 150 000 строк. в целом задача придумалась такая: нужно прописать некоторым страницам сайта количество уникальных просмотров. При этом предусмотреть рост посещаемости, как постепенный, так и скачкообразный (на прошлой неделе в какойто день к обеду было уже 45 000 человек и 800 000 просмотров).
Есть список чуть меньше 20К страниц, для которых нужно посчитать уников за определённый период. На входе есть этот урл, виде срс32, он же есть в таблице с просмотрами, в которой в худшем случае 150 тысяч строк, в лучшем (для кошелька) - 800-1000 К. Берём каждый урл из 20 тыс, находим в таблице, куда записываются просмотры и считаем количество уникальных элементов в такой выборке. Урлы, которые нужно искать лежат в другой таблице (извлекаются туда предыдущей операцией з большой таблице с просмотрами, занимает пару секунд, перебор-инсерт с условиями). Играюсь по всякому.
Такой метод требует в 300-500 раз дольше времени.
INET_NTOA делает тоже самое, только уже в базе. Эта функция применяется ещё при изначальной записи статистики в базу. На момент обсуждаемой операции мы имеем уже базу, где грубо говоря два целочисленных столбца - урл и айпи.
Структура примерно такая:
1 таблица: Каждая строка соответствует одному просмотру страницы, в ней два числа, одно - урл, второе - айпи, записанное туда функцией INET_ATON. Контрольная выборка для замера 150К строк.
2 таблица: список урлов где они не повторяются. 20К строк.
Вся обсуждаемая операция прописывает во второй таблице значения уникальных просмотров данного урла, содержащихся в первой таблице. :) Запросто может быть какойто хитрый умный путь сделать это одним запросом, я какгрицца не волшебник, тока учусь, и нужно это всё в принципе просто фор фан ))
nocomments добавил 01.12.2010 в 23:24
А тут немного другая ситуёвина, 8 ядер по 1,6Ггц, 8 гиг памяти и всё практически эксклюзивно под этот проект :)
Ждал пока накопится вчерашнее количество, чтобы сравнить скорость. После изменение формата записи айпишников в базу, получилось 3 минуты, т.е. как средствами php, отлично, резерв есть. Как записать в виде 4 байт не понял, если конвертить через chr - получается абракадабра (некоторые символы непечатные, не знаю как отнесётся к этому varchar). Записываю в виде INET_NTOA('x.x.x.x') в поле unsigned int. В принципе выигрыш значительный, solved.
seraphim, если 0.7 сек это один запрос - это очень очень много, речь про время работы скрипта на обработку такого запроса 15-20 тысяч раз.
Dreammaker, спасибо, сейчас изменил запись ip со строки на INET_NTOA(...), накоплю количство элементов, посмотрю что там со скоростью.
Dreammaker, об этом пересчёте и идёт речь. При количестве урлов около 20 000 и количестве записей 150 000 обработка через выбоку SELECT DISTINCT идёт 10 минут. Простым перебором всех 150 тысяч - 3-4 минуты.
вот это даже не подумал. нужно покопать в этом направлении. спасибо!
По поводу текстовых лог-файлов, тут не очень подходит, нужно не просто количество, нужно количество уников по определённым страницам, поэтому параллельно идёт выборка, и этот запрос выполняется несколько тысяч раз.
nocomments добавил 30.11.2010 в 20:19
Вот это как раз такая обработка, просто исходные данные сразу в базе удобнее
Cufon пользую, любой ttf шрифт подходит, посетителю ничего качать и устанавливать не нужно. Если отключит - будет видеть стандартный шрифт.
Haker, ну людям какбы пофигу какие там у вас тексты, обновляется ли ваш сайт и как вы его называете.
Делайте чтобы народ ломился и ссылку друг другу передавал, остальное всёравно.
nocomments добавил 30.11.2010 в 17:27
И ещё микросовет, пишите просто "сайт", для кого он - чужая точка зрения не интересует в этом вопросе.
Это рейтинги посещаемости, подсчёт уникальных ip, от текстовых файлов для этого уже ушёл, в данном случае база предоставляет высокий уровень экономии.
Xoce, спасибо, результат получается тот верный, но это ещё дольше, ваш вариант 0.2240 сек., DISTINCT/num_rows 0.0007 сек. Вопрос в том, почему php эту операцию обрабатывает в три раза быстрее чем DISTINCT.
