Парсинг больших XML

Обсуждение сервиса товарной рекламы Микс-Товары
Ответить
Tash
Сообщения: 3
Зарегистрирован: 05 июл 2010, 23:10

Парсинг больших XML

Сообщение Tash » 06 июл 2010, 00:31

Добрый день, форумчане. Интересует такой вопрос, кто-нибудь писал парсинг для разбора XML размером порядка 120М (примерное кол-во товаров 200000)? На форуме ничего подобного не встречал, максимум 25М и то по стандартной схеме занесения всего добра в массив.
На данный момент я написал парсер, он нормально обходит весь файл, но чем глубже тем медленней, плюс занесение 200000 тысяч записей или апдейтов идет медленно, в общем за 7 часов обработки файла, 3 раза переписанный скрипт смог обработать максимум 130000 заказов, хотелось бы все получать и хотя бы за 4 часа выгрузки:)
Кто может поделиться опытом? Пишу на ПХП под битрикс, но суть смогу понять на любом языке, если донесете.
Заранее спасибо.

ЗЫ хостинг обычный от зеноне, думаем о переезде на ВПС, но есть сомнения, что это увеличить производительность обработки в 4 раза.

MarquusGun
Сообщения: 59
Зарегистрирован: 05 ноя 2009, 22:49

Re: Парсинг больших XML

Сообщение MarquusGun » 06 июл 2010, 05:05

Имел опыт обработки таких больших прайс-листов. ОБрабатывал достаточно быстро, но не секунды, так как все же к МайСкулу надо было много запросов делать к активным таблицам. Спасение было в том, чтобы формировать таблицу, которая будет потом будет вместо основной, то есть, данные вставлять в пустую, а потом ее переименовывать.
Но как время показало, я отказался от такой затеи и ушел в многократный разбор небольших прайсов, так как здесь есть свои плюсы, а именно: а) в случае сбоя, не обработается лишь текущий, а предыдущие и последующие, вероятно, будут с успехом закончены; б) нагрузка распределена по времени на большие срок, что дает возможность высвобождать ресурсы для WEB запросов и ответов, то есть, для меня лучше 10 раз повесить табличку (образно говоря) "на обслуживании" на 3 минуты, нежели один раз , но на полчаса.

Да, вот еще, не использую XML средства PHP для разбора прайс-листов.
Не гружу весь файл в ОП сервера, хотя мощность позволяет.
Не использую у хостера ВиртуалХостнг, использую Deticated сервер.
P.S. VPS миеня в свое время не спас. Точнее, на VPS все работало, но ресурсы капитально пожирались. Мне ничего не оставалось, как перейти на Deticated, о чем никогда потом не жалел.

ilyaska
Сотрудник Миксмаркета
Сотрудник Миксмаркета
Сообщения: 79
Зарегистрирован: 22 янв 2007, 17:01

Сообщение ilyaska » 06 июл 2010, 11:38

1. Если еще не используете, то пора использовать SAX парсер, вместо DOM
2. Данные не обязательно сразу писать в mysql, гораздо быстрее складывать в файл, а потом один раз сделать LOAD DATA INFILE
3. Практика показала, что на php занесение добра в массив ни к чему доброму не приводит, поэтому на больших объемах данных лучше отказаться от такой схемы.

Tash
Сообщения: 3
Зарегистрирован: 05 июл 2010, 23:10

Сообщение Tash » 06 июл 2010, 13:25

от DOM парсера отказался сразу, использовал XMLReader (на сколько знаю, он вроде SAX) , но в конце вообще товары стал обрабатывать руками, забирать по строчно и искать там <offer> производительность немного поднялась, SAX примерно так же и работает...
Идея с занесением всех команд MySQL в файл, а потом его выполнить приходила, но после 3 разов переписки парсинга и малой прибавки эффективность, появлялись сомнения:) за идею спасибо, наверное буду в 4 раз переписывать.
Других идей по ходу нету? Да и сам уже не знаю, что можно придумать.

Tash
Сообщения: 3
Зарегистрирован: 05 июл 2010, 23:10

Сообщение Tash » 07 июл 2010, 17:42

Отпишусь, если кому-то в будущем понадобится. Самым узким местом, как все и предполагали был MySQL после добавления несколько десятков тысяч записей, скорость добавления падает на порядок и оптом снижается, а если делать апдейты записей, то это еще медленней. Решено было не писать в БД сразу, а записывать запросы к БД в файл, а после обработки всего XML сделать кроном развертку дампа через утилиту mysql. Так же из-за того, что хостинг обычный была проблема со временем работы скрипта, пришлось сделать поэтапную обработку, экспериментально получилось, что скрипт запущенный в кроне выполняется 5 минут, если больше иногда хостинг его "killed", поскольку парсер был написан руками, то с этим не было проблем: запустил отработал 5 минуты, сохранил позицию каретки в читаемом XML и закончил скрипт, крон выполняет следующий через 5 минут, пошагово все создается.
Итог:
обработка XML размером 125М и запись команд в файл идет порядка 1 часа, чаще быстрей, файл sql получается 100М
развертка этого 100М файла в БД занимает - 5 минут не больше.
Товаров получилось 217000

Тестировалось днем при нагрузках, ночью думаю будет все быстрей.
ВПС тоже попробовал (1000МГц 825М) настроен у хостеров оказался плохо, да и прибавки в производительности было очень мала, а если учесть что стоимость в 2 раза больше, то совсем не вариант.

Спасибо за идею с с записью запросов в файл, верней за толчек делать этот вариант:)

Аватара пользователя
skifbiz
Сообщения: 22
Зарегистрирован: 27 ноя 2006, 17:11
Контактная информация:

Сообщение skifbiz » 05 ноя 2010, 17:47

Я писал когда-то такой парсер. Ну не 120 мег, а 50Мб обрабатывал за секунды, практически не нагружая сервер.
напрямую преобразовывал xml в sql и все..

Ответить