Каким способом лучше перерабатывать многомиллионые логи?

Question

[Андрей]

Доброго времени суток сообщество.
Суть задачи: еженедельно обрабатывать логи в 50кк-80кк строк.

Есть mysql база с уникальными полями в 25кк строк, со временем собираются необходимые логи и нужно обновить инфу(счётчики + дополнительные поля).

Как я сейчас это вижу:
1. Переработать логи убрав дубликаты/суммировать поля. (обычно строк где то 60% от количества строк в БД)
2. Построчно делать запросы к базе (сравнить и обновить/добавить если надо)
Но время работы скрипта растягиваются на часы + очень трудно вывести прогресс работы.

Как можно решить данную проблему? Помогите :)

Как работало раньше. Когда то база была <5кк и я сливал всё в многомерный массив, логи тоже в массиве быстро собирал, сравнивал и обновлял. Но месяц назад мне начало выдавать ошибку с нехваткой памяти, а поднять лимит нельзя, php ведь 32битный. Обновление такой базы протекало не более 2-5 минут.

Comments

[Андрей]

уххх... Вот это ночка выдалась. Все логи записаны.
Спасибо обоим за советы. Реализовал поэтапную заливку логов с сохранением незавершённых ссесий во временной таблице. Работает на удивление быстро :)

Answer 1

[Flaker]

А нельзя обрабатывать не еженедельно, а каждые сутки, например?
К тому же, такого демона реализовать можно(лучше) на C++, и распараллелить.

Comments

[Андрей]

каждые сутки нельзя. минимальный промежуток 5-7 дней должен быть.

По поводу C++, были мысли сделать на нём скрипт (базовые знания имеются). Но я никогда не использовал связку C++ и mysql.

[Flaker]

Ну работе с базами в C++ есть много информации в интернете.

Но можно и на PHP. Основная проблема в кол-во памяти, как я понимаю?
Думаю, можно попробовать парсить логи не полностью, а по чуть-чуть.
Допустим парсим с 1 по 100000, как закончили, очищаем память и парсим с 100001 по 200000, ну и т.д.

Answer 2

[Calc]

tar.gz для хранения
mysql сделайте репликацию, в новой базе сделайте "свои" индексы
По ним и считайте

А вообще ваш лог через unuxовый sort пролезает?
Делайте sort, потом uniq, а работайте уже с выходным файлом.
Обработка через awk

Answer 3

[s1dney]

Там много велосипедов можно придумать с SQL базами/демонами и репликациями, но все они плохо масштабируются и люто тормозят. Если есть тенденция увеличения объема логов, то нужно смотреть в сторону logstash + elastic search, иначе в будущем у вас будет такое легаси, с которым уже сложно будет что-то сделать.