есть текстовый файл с логом и мне ничего не стоит распарсить его и закидать в базу на примере :


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

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

perldoc File::Tail

Добавлено через 31 секунду
или просто tail

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

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

а как быть если файл логов обнулен , тогда счетчик не поможет 

обнулен файл, обнуляй и счетчик, не вижу в чем проблема.

0) Лог не содержащий время - не лог 

1) Если лог размером 1-5 гига, то предложение "при запуске скрипта сравнивать хранимую цифру с реальным кол-вом строк в логе" ОЧЕНЬ сильно нагрузит бессмысленной работой сервер (надо читать 1-5 гигов одного и того же файла при каждом запуске программы)

2) Вам рекомендовал уважаемый arto команду tail - это правильное решение.

3) если же хочется реализовать самому, то посмотрите команды seek и tell. 
Идея такова: Когда Ваша программа в первый раз дочитает лог до конца (с записью в БД распарсенных значений), надо в конце файла вывод команды tell сохранить для следующего запуска вашей программы(в БД или в файле). При следующем запуске вы зачитываете последнее сохраненное значение и встаете на эту позицию файла лога командой seek, пропустив уже отпарсенное. Команда seek работает почти мгновенно, почти не зависит от размера файла и практически не нагружает сервер. Опять читаете лог до конца файла с записью в БД распарсенных значений и записываете новое значение tell в БД или файл. 
Узнать, что файл лога отрезался можно сравнив размер зачитанный из БД и реальный размер файла лога. Если реальный размер меньше, то наверняка файл отрезался. При этом Ваша программа должна читать файл с начала. Правда могут быть нюансы если запуски программы реже чем отрезки файла лога. Если Ваша программа должна работать ТОЛЬКО на UNIX(Linux) я бы для этого кроме размера проверял бы еще i-node файла, так как имя лога обычно бывает одно и тоже, а меняется только сам файл, т.е. i-node.

Никогда не слышали про замечательную команду wc ? На логе 300+mb, wc -l Отрабатывает менее чем за 1 секунду.

Кстати, а что за БД используется Вами? Она поддерживает переменные привязки (bind)?
Я бы на месте админа БД убил бы эту сессию вместе с разработчиком такой проги ;)
Если БД - ORACLE, то код

while(<LOG>){
    my ($ip_temp, $host_temp, $string_temp) = split(/\|/, $_);
$query = "INSERT INTO log (ip, host, string) VALUES ('".$ip_temp."', '".$host_temp."', '".$string_temp."')";
$query_handle = $connect->prepare($query);
$query_handle->execute();
}

очень быстро забьет sql area сервера БД, понизив тем самым общую производительность сервера

код должен быть таким (примерно, я не проверял):

my $query = "INSERT INTO log (ip, host, string) VALUES (?, ?, ?)";
$query_handle = $connect->prepare($query);

while(<LOG>){
    my ($ip_temp, $host_temp, $string_temp) = split(/\|/, $_);
   $query_handle->execute($ip_temp, $host_temp, $string_temp);
}

К моему последнему сообщению: на логе 1.2G результат более плачевный. Так что если файлы большие то вариант мой действительно не проходит.

На логе 300+mb, wc -l Отрабатывает менее чем за 1 секунду. 

Забавно 
А знаете что она (wc) реально делает?
Это говорит, что либо файл уже в кеше, либо сервер ОЧЕНЬ мощный (например дисковая система на внешнем массиве по FC), так как чтение 300MB/секунду это хорошо (естественно если ВЕСЬ сервер не в вашем распоряжении и на нем еще идет полезная работа)

Я против загрузки сервера тупой работой.

да нет , не то это все и сервер ложится при использовании базы , не вывозит нагрузки уже при 10 метровом логе.хоть проц 2 ядра и рама 4 гига .
не вариант юзать базу данных в моем случае , а так хотелось !

box, а ложиться скорее всего из-за, того что Вам ramus написал по поводу prepare и execute 

А почему она должна ложиться?
Я всегда думал, что prepare statement наоборот помогает, позволяет держать базе в кэше объект SQL statement, что избавляет от необходимости
каждый раз парсить запрос.

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

Ну ведь он, это и советует:
Не надо:


То есть prepare происходит для каждой записи, что неправильно - и по идее одно и то же, что вставка без prepare.
И как должно быть 



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

Разве это не правильно?

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

"хоть проц 2 ядра и рама 4 гига ."

У нас особо "одаренные" программисты таким образом "напрягали" гораздо более крутой сервер - 8 двухядерных итаниумов с 64 гигами оперативки.
Я не говорю, что это предложение панацея от всего, но то, что надо один раз отпарсить SQL, а потом многократно использовать с разными данными-это существенно облегчит жизнь серверу и админу.

"что prepare statement наоборот помогает, позволяет держать базе в кэше объект SQL statement, что избавляет от необходимости
каждый раз парсить запрос."
Как раз в Вашем варианте происходит парсинг для каждой строки лога, так как каждый раз строка разная, например
INSERT INTO log (ip, host, string) VALUES ('1.1.1.1', 'host_temp', 'string')
INSERT INTO log (ip, host, string) VALUES ('2.2.2.2', 'host_temp', 'string')

В предложенном мной варианте парсинг (в том числе определение плана выполнения) выполняется один раз, 
INSERT INTO log (ip, host, string) VALUES (:ip, :host, :string)
в области хранения SQL запросов ( SQL area) будет только ОДНА строчка (от нашей сессии). Число execute для нее будет равняться числу строк в логе.

В Вашем же случае число строк в sql area БД будет равно числу строк в логе и для каждой такой строки число execute будет =1.

PS
Лучше много раз по разу, чем ни разу много раз ;)

пишу следующее :

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

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

Добавлено @ 11:29

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

Это сообщение отредактировал(а) shamber - 26.1.2010, 11:30

box, у меня вот какой вопрос возник: если у Вас лог периодически обнуляется и этот процесс никак не завязан со скриптом, Вы, случайно, часть данных не теряете (которые добавилась после запуска скрипта, но до обнуления лога)?

"ну добавьте в скрипт, чтение параметров файла, к примеру время последней модификации. и все проблемы решены"

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

что в моем предложении, мешает осуществить перечисленное вами?


Это сообщение отредактировал(а) shamber - 26.1.2010, 17:05

интересно, когда вы повторите функциональность обыкновенного tail?
который может следить хоть за дескриптором, хоть за именем...

приведите пожалуйста пример использования tail  в перле , а то я нашел только для командной строки .

А почему не хотите использовать tail коммандной строки из perl ? 

tail | perl самое простое.
либо perldoc -f open

Дак можно прямо в перл получать результат tail

нет.
я так понял, что вы не прочитали man tail ? 

не совсем понял, какоe отношение имеет способ вызова tail к прочтению/не прочтению мною man'а.

а вы прочитайте.

В мане есть опция, позволяющая tail отследить смену файла.

Это сообщение отредактировал(а) mvsgt - 27.1.2010, 00:12