Odissey Nemo

Если имеется в вижу, что есть множество мелких файлов XML общим объёмом 100Мб-1Гб, то применял следующие методы:
1. StringBuilder с заголовком, далее в него дописываю выдранные с помощью RegEx содержимые каждого из XML. В конце записываю в StringBuilder в шапку что требуется (например, число обработанных файлов), добавляю хвост интегрального XML - и вуаля.
2.Если не требуется шапку менять в конце работы, то открываю новый ZIP файл и пишу в его поток, который идёт сразу на диск (или в память, как требуется по ситуации). Получается ещё компактнее, раз так в 20-30 по памяти.
3. Можно и просто в буферизованный файловый поток писать, опять-же (см. пункт 2).

Выдирал всегда RegEx'ом только потому, что условия были простыми: найти начальный и замыкающий теги нужного куска XML. Если желательно форматирование, то можно слегка подшаманить при добавлении очередного найденного куска с дополнительными пробелами, табуляциями и \n(\r).

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