crmMaster
@crmMaster

Какая библиотека самая эффективная на данный момент в задачах парсинга XML?

В нашем проекте остро встал вопрос увеличения эффективности XML парсинга.

Наша основная задача - парсинг ответов SOAP сервисов. В данный момент используем Nokogiri (Ruby), но даже c C++ оптимизациями ее эффективность крайне низка.

Эффективность для нас - это скорость выполнения задачи в условиях бесконечно доступных ресурсов. Nokogiri в этом плане крайне печальна, т.к. не работает в многопоточном режиме и содержит много ненужной нам функциональности.

Платформа и язык опять же не имеют значение - умели бы работать с unix-socket, а дальше все уже готово :)

В теории, Erlang-реализация могла бы стать более эффективной из-за многопоточной архитектуры, но грамотные реализации на C++, Rust или Java располагают теми же системными возможностями.

Вот и хотелось бы собрать самые лучшие библиотеки всех миров чтобы столкнуть лбами на реальной задаче.

Ну а что действительно лучшее - хотелось бы услышать от вас.

P.S. Парням "выкинь либу, юзай поиск подстроки" просьба пройти на www.coursera.org какой-нибудь курс по обработке данных и больше не советовать откровенных глупостей.

P.P.S Еще более упоротым парням "перепиши все на ассемблере под куду", советую и дальше упарываться ассемблером под куду. У нас тред про robust решения
  • Вопрос задан
  • 597 просмотров
Решения вопроса 2
@Plus3x
Думаю что стоит начать с исследования инструментов на том языке разработки www.ohler.com/dev/xml_with_ruby/xml_with_ruby.html
Ответ написан
begemot_sun
@begemot_sun
Программист в душе.
Чистый Erlang вам не нужен.

ну есть какойнить
https://github.com/processone/fast_xml
Ответ написан
Пригласить эксперта
Ответы на вопрос 3
sim3x
@sim3x
lxml

при чем там сокеты, "параллельность обработки" и др вещи совсем неясно

Паука / скраппера можно писать на чем угодно - и ето не повлияет на скорость парсинга и построения дерева xml
Ответ написан
@odissey_nemo
Программист, ГИС-системы, растры, космоснимки
Для обработки (парсинга) XML есть два идеологически различающихся подхода:
а) DOM, когда считывают весь XML в память, строя в ней полную иерархию структуры и
б) SAX - когда проходят по файлу вдоль него, посещая все элементы один раз, причём последовательно.

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

SAX работает максимально быстро (на 1-2 порядка быстрее, чем DOM) но может потребовать реализации сложной логики хранения нужных данных, если логика задачи также потребует возврата к данным предыдущих элементов.

И DOM и SAX имеют устойчивые и надёжные реализации для всех языков и операционных систем мира. Выбор между ними зависит только от задачи и среды разработки.

Есть и смешанные подходы, в частности JAXB - когда с помощью SAX считывают и помещают данные XML не в DOM объект, но в примитивные объекты классов языка, на которых уже и реализуется конкретная бизнес-логика. Проблема JAXB в том, что он может обрабатывать ТОЛЬКО уже известные ему структуры XML, т.е. практически это компиляция XSD в Java/C# и т.д. код. Поменялась XSD - меняй и Java/C# и т.д. код и адаптируй логику программы под новые данные. Зато - максимум достижимой эффективности в процессе работы.

Я лично всегда выбираю SAX, т.к. однажды, лет 10 назад, наблюдал большие затруднения по работе с многосотмегбайтными XML при использовании DOM. При том, что внутри были просто сотни тысяч отдельных мелких логически независимых единиц информации (телефонные счета для рассылки клиентам). А на SAX решили эту же задачу тупо и в лоб, по API документации, без каких-либо хитростей и проблем.

В чём проблема больших объектов DOM? В том, что им требуется много-много маленьких кусочков памяти. А это есть самый плохой случай доступа к данным, как для оперативной памяти, так и для дисковой. Каждый наблюдал это явление, когда запись файла может занимать в десятки раз больше времени, чем его считывание. Собственно, вся обработка данных чисто исторически затачивается на считывание многих данных (кэширование!!!) и запись немногих (write through). Один раз обновил - считывай сотни раз. Именно под такую логику и разрабатываются и оптимизируются процессоры, память, диски, софт!

Насчёт многопоточности - это вопрос не обработки одиночного XML, а а способов слияния результатов обработки отдельных XML в общую БД. Так и так каждый отдельный XML объект может быть обработан ТОЛЬКО в одном потоке. Так уж он устроен. Если представить себе какой-то гигантский XML, структура данных которого позволяет параллельную обработку, то всё равно хотя бы раз его придётся полностью пройти в одном потоке, чтобы разделить на автономные единицы параллельной обработки.

Кстати, Oracle умеет достаточно эффективно обрабатывать поля своей БД, содержащие XML. И делает это именно через SAX )))
Ответ написан
al_gon
@al_gon
"умели бы работать с unix-socket" и задачи парсинга XML я бы не смешивал.
Java:
Если простые данные, но сразу в большом объеме, то https://ru.wikipedia.org/wiki/SAX
Если комплексные и не в большом объеме (помещаются в память) то https://ru.wikipedia.org/wiki/Java_Architecture_fo...

Если комплексные и не помещаются в память то комбнация из SAX и JAXB.
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы