Алгоритм парсинга лога реферов и переноса его в БД.

[REMO]

Алгоритм парсинга лога реферов и переноса его в БД.

При заходе на сайт скрипт пишет в фаил лог реферов.

Задача: проанализировать лог, сгруппировать данные и перенести их в БД.

Интересует общий алгоритм всего этого действа.

Т.е. допустим у нас в БД уже хранится какая то обработанная инфа по логу. И каждые 15 минут, мы запускаем скрипт, который парсит фаил лога, приводит данные в порядок и сует их в БД.

Мой вариант: читаем данные из БД в массив, чиатем фаил лога в другой массив, упорядочиваем данные в соответствии с поставленной задачей. В результате обработав массив 2, мы переместим данные из него в массив 1 (в который прочитали БД).

Вставляем в цикле обновленный массив 1 в БД.

Минусы на лицо: инклюд в цикле это есть очень плохо.

Можно конечно все это дело в фаиле хранить и не мучать БД. Т.е. упорядочили все в массив 1 и засунули его в фаил. ИМХО очень даже хорошо.

Но хоца услышать мнения других (прежде чем сделать или не сделать ошибку), может кто то сталкивался?

THNX

 

[Кром]

include тут никаким боком, на самом деле.
А так вобщем все нормально. Только лучше сначала все перенести в базу, а потом группировать данные уже в самой базе, без обработки их во вноешних массивах.

 

[REMO]

Автор оригинала: Кром
include тут никаким боком, на самом деле.
А так вобщем все нормально. Только лучше сначала все перенести в базу, а потом группировать данные уже в самой базе, без обработки их во вноешних массивах.

Не инклюд, инсерт конечно, обшибся малек

Я то как раз наоборот, все сначала из базы вынимаю, а обработав засовываю, чтолбы базу меньше дергать.

А как это сначала в базу все засунуть, а потом уже в ней все приводить в порядок? Видимо я чего то упускаю, но я замучаю базу запросами

 

[IntenT]

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

 

[REMO]

Автор оригинала: IntenT
REMO
положить одну запись - один запрос.
достать интересующую статистику - тоже 1-2 запроса.
к тому-же достается статистика гораздо реже, чем добавляется

В том то и проблема, что достается реже, чем добаляется... Инсерт то более затратоемкая операция, чем селекс, насколько я понимаю.

Да и смыслс сначала все сувать в базу, а потом обрабатывать. Я просто не пойму, что я от этого выиграю? Удобство, нет. Скорость, тоже нет. Или я что то упускаю из виду?

 

[IntenT]

REMO

Инсерт то более затратоемкая операция, чем селекс

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

Да и смыслс сначала все сувать в базу, а потом обрабатывать

а смысл в том, чтоб складывать где-то, потом потрошить базы и это что-то, потом снова насиловать базу есть??

Удобство, нет

Таки да

Скорость, тоже нет

снова да

Или я что то упускаю из виду

упускаешь. что именно - читай выше

 

[_RVK_]

REMO Не пойму в чем проблема? Я как то писал парсер логов сквида, так делал так:
выбирал из базы время последней записи. Потом парсил лог, и добавлял только те записи которые были добавлены позднее. Зачем масивы? Все просто как топор. Так логи сквида думаю поболя будут твоих...

ЗЫ. Преждевременная оптимизация - зло

 

[REMO]

Автор оригинала: IntenT
REMO
а смысл в том, чтоб складывать где-то, потом потрошить базы и это что-то, потом снова насиловать базу есть??

А мне не нужно хранить в базе копию лога, т.е. в базе должен лежать лог обработанный и сгруппированный так как мне надо. Т.е. вариант засунуть все как есть в БД, а потом доставать в том виде какой требуется смысла не имеет имхо. Проще сразу обработать в нужном виде и сунуть в базу. Зачем создавать таблицы с 50К-100К записей, проще создавать обработанные. Я не прав?
Смысл в этом.

насчет скорости и удобства согласен, если бы мы просто весь лог скопировали в БД, удобно и быстро. А если обрабатывать?

Автор оригинала: Diesel
Diesel

Не пойму в чем проблема? Я как то писал парсер логов сквида, так делал так:
выбирал из базы время последней записи. Потом парсил лог, и добавлял только те записи которые были добавлены позднее. Зачем масивы? Все просто как топор. Так логи сквида думаю поболя будут твоих...

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

 

[IntenT]

REMO

Зачем создавать таблицы с 50К-100К записей, проще создавать обработанные. Я не прав?

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

IntenT

Не пойму в чем проблема? Я как то писал парсер логов сквида, так делал так:

неправда, не мое это ))

 

[voland]

кроме той, что ты уже наобрабатывал

Но ведь ты можешь обработать все! Никто не мешает тебе вынуть оттуда вообще ВСЁ...

 

[REMO]

Автор оригинала: voland
Но ведь ты можешь обработать все! Никто не мешает тебе вынуть оттуда вообще ВСЁ...

Мене усе не надо, мне тока то что дохтур прописал
Короче я боялся инсерта в цикле, а во всем остальном это уже отступление от темы.
Поэтому буду делать как и делал, но обработанное сувать не в БД, а в фаил. И быстрее и надежнне. А потеря функциональности не особо будет заметна будем надеятся

 

[_RVK_]

REMO просвящаю. SQUID это проксисервер, самый распространеный под Linux.
1. Зачем тебе нужна эта информация? Если для статистики, то почему не вся?
2. 50-100К записей это немного.
3. Лично я брал запись из файла, парсил регом и тут же засовывал в базу, если она не старше последней по времени в базе. Я не могу понять, зачем масивы и причем здесь файлы. Наверное нужно получить ответ на пункт 1. прежде чем понять п. 3....

 

[REMO]

Автор оригинала: Diesel
REMO просвящаю. SQUID это проксисервер, самый распространеный под Linux.
1. Зачем тебе нужна эта информация? Если для статистики, то почему не вся?

Ну почему не вся, просто она мне нужна определенно сгруппированная. И я не вижу смысла сувать сначала ее всю в БД, а затем если нужно просмотреть обрабатывать ее. Я ее лучше сразу обработаю, а потом засуну в нужном мне виде. Сгруппированном и с сэкономленным местом в БД.

Я не могу понять, зачем масивы и причем здесь файлы.

Массивы выполняют функцию временного хранилища, используемого для привдения данных в необходимый вид. А ИМЕННО ИХ ГРУППИРОВКИ.

 

[_RVK_]

REMO как ты их будешь групировать? чем тебя не устраивает SELECT....ORDER BY...? Я, ну хоть убей, не пойму зачем тебе массив. Мне кажется что ты что то неправильно делаешь, ну никак не покидает такое чувство. Если бы ты привел пример лога, и сказал что ты хочешь выкинуть и по чем групировать, думаю тебе бы ответили на твой вопрос: "Но хоца услышать мнения других (прежде чем сделать или не сделать ошибку), может кто то сталкивался? "

 

[REMO]

Автор оригинала: Diesel
REMO как ты их будешь групировать? чем тебя не устраивает SELECT....ORDER BY...? Я, ну хоть убей, не пойму зачем тебе массив. Мне кажется что ты что то неправильно делаешь, ну никак не покидает такое чувство. Если бы ты привел пример лога, и сказал что ты хочешь выкинуть и по чем групировать, думаю тебе бы ответили на твой вопрос: "Но хоца услышать мнения других (прежде чем сделать или не сделать ошибку), может кто то сталкивался? "

Напомню это лог реферов.
Группирую я их след образом. Если встречается идентичный реферер, то в базу он пишется не 2 раза, а один и в колонке cnt ставим 2. Т.е. cnt это сколько раз он повторися.

Смысл:
1) уменьшить размер таблицы
2) зачем делать работу 10 раз, елси можно один. Т.е. так скрипт один раз работу сделал и все ледит в нужном виде. А так придется каждый раз ему группировать лог из базы.

Ой чувствую запинают меня чичас, ой чувствую

 

[.des.]

Напомню это лог реферов.
Группирую я их след образом. Если встречается идентичный реферер, то в базу он пишется не 2 раза, а один и в колонке cnt ставим 2. Т.е. cnt это сколько раз он повторися.

Хм..
а когда именно этот реферером был источником посещения в первый раз, а когда во второй?
Если Вы хотите написать полезную статистику, то очень важно кто и откуда к Вам приходит за промежуток времени.

 

[REMO]

Автор оригинала: .des.
Хм..
а когда именно этот реферером был источником посещения в первый раз, а когда во второй?
Если Вы хотите написать полезную статистику, то очень важно кто и откуда к Вам приходит за промежуток времени.

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

 

[Alien]

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

 

[zahhar]

Re: Алгоритм парсинга лога реферов и переноса его в БД.

Автор оригинала: REMO
читаем данные из БД в массив. [...] обработав массив 2, мы переместим данные из него в массив 1 (в который прочитали БД). Вставляем в цикле обновленный массив 1 в БД.

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

Несколько сотен или даже тысяч insert-запросов в 15 мин не завалят базу (конечно, если таблица не перегружена индексами. Если это так - то может иметь смысл сброс индексов перед заливкой и пересоздание их после завершение операции. Или же строить индексы только перед выборками, если выборки происходят существенно реже, чем заливки - 1-2 раза в день против 100-200).

Но межет быть имеет смысл делать не инсерт, а что-то вроде
update tebale set field=field+[новое значение из обсчитанного массива] where fileld2=[поле группировки массива]
?

В заключение позволю совет из личного опыта: лучше сохранять в базе максимально детальную информацию, включающую всевозможные подробности. Ибо построить по ним любой отчет - дело нескольких запросов, а разгруппировать однажды сгруппированные данные невозможно. Если база растет очень быстро - миллионы записей в неделю, то можно неактивную информацию переносить в архивы. Для чего это нужно? А никогда заранее не знаешь, для каких целей, кому и когда понадобится информация. Сегодня заказчик хочет видеть только с каких сайтов ходят на его сайт, а через год его будет интересовать димамика посещяемости - с каких сайтов за последний год кол-во пришедших на его ресурс заметно снизилось? С какой даты началось снижение? и т.п. Ответить на такие вопросы можно только имея подробную несгруппированную статистику за долгий период. А задаются такие вопросы обычно в "переломные" для жизни сайта или фирмы времена.