Xpoint
   [напомнить пароль]

Разбор XML большого объема

Метки: [без меток]
[удл]
2008-08-06 12:47:32 [обр] Александр Петров(2/4)[досье]

Требуется распарсивать Commerce ML. Вотпример формата. Как можно предположить файл может быть достаточно большой.

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

Сначала склонялся к SAX, но ввиду второго абзаца, теперь не вижу в этом особого смысла (Каждый раз весь файл перебирать). Как оптимизировать разбор файла по отношению к системным ресурсам

спустя 5 часов [обр] Давид Мзареулян(536/1003)[досье]
Мне кажется, лучше разбить задачу на две: разбор файла и запросы-выборки из него. Судя по Вашим словам, выборки будут не единичными и слабопредсказуемыми. Тогда, может быть, проще при поступлении файла парсить его SAX-ом, данные скидывать в базу, и уже оттуда выбирать как угодно?
спустя 16 часов [обр] Александр Петров(2/4)[досье]

Давид Мзареулян[досье], я тоже к такому подходу склоняюсь. Только идея была с массивами. Распарсить все блоки документа в массивы и потом с массивами работать. Массивы тоже память отожрут, но намного меньше и скорость больше.

....данные скидывать в базу, и уже оттуда выбирать как угодно?

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

  1. Я хотел написать класс parseCommerceML который работает с массивами;
  2. Написать класс Base работы с базой заданной структуры. (Что-типа добавить товар $baza->addTovar(id). Вся SQL логика внутри)
  3. Парсить XML (parseCommerceML) и помещать в базу (Base)

Теперь передо мной делема, хранить этот документ в том виде в котором он есть в базе не удобно (И как ввобще хранить XML в базе?????). Значит это промежуточный формат. Затем необходимо создать новую базу с более читаемой структурой. Или просто выкинуть все промежуточные пути и парсить документ в базу сразу с "понятной и легкой" структурой. Но тогда процесс парсинга усложниться и код тоже. Лучше конечно с точки зрения моей логики разделить процесс парсинга файла и процесс помещения данных в базу. Куда лучше?, считать XML в массивы или в промежуточную базу. Вообщем над алгоритмом надо еще поразмышлять....

спустя 3 часа 44 минуты [обр] Александр Петров(2/4)[досье]
Наткнулся вот на такую реализацию хранения XML в базе http://dev.mysql.com/tech-resources/articles/mysql-5.1-xml.html
Наверное это будет производительнее чем DOM модель?!
спустя 17 часов [обр] AB...(0/233)[досье]
С XML в MySQL я не знаком, но это напоминает реализацию Oracle. В принципе это тотже XPath. В Oracle это реализована на Java. Как это сделано в MySQL я понятия не имею. Одно могу сказать, что необходимо смотреть скорее всего на длительное использование, количество обращений, количества XML файлов. Если действительно большой объем файлов и разбит по дополнительным категориям и еще чего накручено, то имеет смысл идти на DB.
Если же все проще, то я лично бы использовал, согласно вашего первого сообщения, XML::XPath или XML::DOM. Но скорее всего будет тостаточно XML::XPath.
Из своего опыта могу сказать, что была задача фильтрации данных по 3-5 параметрам с дополнительными условиями из XML файлов, где объем записей был действительно огромный. Учитывая, что каждый node name и attribute name не превышал 5-ти символов файлы были от 20 до 50 Mb. Так самые большие файлы с максимальными параметрами фильтрации на основе XML::DOM не превышали 7 минут.
спустя 2 часа 35 минут [обр] Александр Петров(2/4)[досье]
Спасибо всем за комментарии. Я пришел к выводу что оптимальным для моих условий будет преобразование древовидной структуры XML в реляционную. Тем более что структура совсем не сложная и запросто можно трансформировать.
Powered by POEM™ Engine Copyright © 2002-2005