Частые однотипные выборки. Ускорить бы процесс.

[katch]

Частые однотипные выборки. Ускорить бы процесс.

Прошу совета.
Я читаю большой (до 4 гб) текстовый файл (лог за день). Выделяю нужную информацию и ОБНОВЛЯЮ соответствующие выделеной информации записи в БД (MySQL пока что). Учитвая сколько записей в логе, сколько записей в таблице, и что сравнение идет НЕ по ключевому полю (даже по двум не ключевым полям), более того - текстовому(хотя реально там практически никогда не задействовано больше 255 символов) и символьному, процесс получается невыносимо долгим.

Что можно сделать, чтобы ускорить процесс ? MD5 и ключ ?

 

[Кром]

Стоп, стоп, стоп! Пока ничего нельзя сказать, просто потому, что информации слишком мало.

>процесс получается невыносимо долгим.

Любой процесс можно разделить на несколько этапов. Хотелось бы знать где именно происходит наибольшая задержка.

>сравнение идет НЕ по ключевому полю

Т.е. сравнение идет, а индексов нет? Почему?

>Учитвая сколько записей в логе, сколько записей в таблице

Так сколько записей?

И наконец, неизвестно как выглядит сам процесс поиска, обновление и т.д. Там может быть неоптимизированный запрос/регулярно выражение и т.д. Не зная этих подробностей ничего пока сказать нельзя.

 

[katch]

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

>>Т.е. сравнение идет, а индексов нет? Почему?
Эмм... это я опять тупил))). Таблица изменилась. Раньше был один индекс в другом поле. Щас еще добавлю один (из этих двух полей, по которым идет выборка вместе взятых).

>> Так сколько записей?
Сколько их в логе - подсчитать проблематично, но, ценных для моей программы записей, думаю порядка 1.5-2млн. В таблице записей порядка 100 000.

>> Там может быть неоптимизированный запрос/регулярно выражение и т.д.

Хмм... а что подразумевается под оптимизаецей запроса ? Регулярные выражения не используются. Проверяется точное совпадения дфух полей двум значениям. Если найдена такая запись (а она абсолютно точно сужествует в единственном экземпляре), то обновляется значение третего поля. Бональный UPDATE ... SET .... WHERE fld1="text" AND fld2="char(255)"

Вот

 

[Dreammaker]

UPDATE ... SET .... WHERE fld1="text" AND fld2="char(255)"

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

Я так понимаю, при совпадении увеличивается некий счётчик?

Если это так и идет только апдейт, то я предложил бы, заранее вычислить для всех строк хеш md5 (как для text, так и для char(255)) и занести в их отдельные ячейки.

Затем при парсинге вычислять md5 тоже и нанизывать его на запрос, который потом отправить в базу. Если не сдохнет скрипт или база, то будет должно работать быстрее.

Но вообще-то, нужно время мерять..

 

[katch]

>> Затем при парсинге вычислять md5 тоже и нанизывать его на запрос

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

>> Но вообще-то, нужно время мерять..
Последний парсинг логов обещал сие действие продолжитеьностью ~10-13 часов. Что, недопустимо. хотелось бы максимум 2-3 часа. Таким временем я могу спокойно рисковать.

 

[Dreammaker]

>Собсно, что и хотел делать...
Пару раз внимательно читал первый пост и так же внимательно забывал о последней фразе. :Одним словом, провтыкал я..

О времени я говорил относительно экспериментальных решений.

Основная проблема здесь в долгом времени парсинга, как по мне ибо 100 000 записей обновить... пусть и с самым захудалым и не оптимизированным запросом несколько часов будет делаться разве что на "Робике" (выпукались у нас в городе в полусоветские времена такие полукомпьютеры-полуклавиатуры).

Скорее всего проблема в парсинге. Что из себя лог представляет?

 

[katch]

>> О времени я говорил относительно экспериментальных решений.
так относительниних я и ответил

>>Основная проблема здесь в долгом времени парсинга
Но основная нагрузка то на mysqld-max.

З.Ы, Лан, седня вечером проведу второй эксперимент. Сделаю составной индекс из полей по-которым ищу. Замерю, сколько времени продолжатся будет. Если опять больше 2-3 часов, буду думать над md5.

 

[Кром]

>я так понимаю на выборке, требуемой бля обновления записи.
>Но основная нагрузка то на mysqld-max.

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

>Регулярные выражения не используются. Проверяется точное совпадения дфух полей двум значениям.

Да, мне тоже интересно, что из себя представляет лог.

 

[katch]

>> Я так и не понял, где главные тормоза. На выборке из текстового файла или в момент внесения в mysql

На нахождении (выборке) нужной записи в таблие БД. Т.е. записи, поле которой необходимо обновить. Грю же, тупил я... небыло индекса на этих полях, вот, походу, и просматривалась вся таблица, при каждой вставке. Ошибку осознал, вечером проверю, как поможет, дожно существоенно помоч )))

-~{}~ 28.03.06 00:38:

я лузер. Простите за беспокойство, народ )) Добавление составного индекса решило проблему на отрез. На выполнение задачи уходит максимум 5 минут (4гб лог), в зависимости от количества выдираемой из лога инфы. Причем нагрузка перелегла в большую степень на чтение лога.(примерно 60% против 30% на мускль). Меня такое время устраивает за глаза )) Да и алгоритм обработки лога мне оптимизировать проще, иба хоть четко понимаю все узкие места))))

З.Ы. За сим откланиюсь...... )))))