Для обработки (парсинга) 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 )))
Средний
