Разделение больших файлов XML в Java

Важным моментом является то, что мы продолжаем перебирать исходный документ и проверяем наличие начала элемента Data. Если это так, мы направляем соответствующий элемент и его элементы на выход. В нашем простом примере у нас нет братьев и сестер, только текстовое значение. Но если структура более сложная, все нижележащие узлы будут автоматически скопированы в выходные данные. Каждые два элемента данных мы будем циклически повторять наш выходной файл Модуль записи закрывается и инициализируется новый (эту проверку, конечно, можно заменить проверкой размера файла вместо% 2). Если средство записи закрыто, оно автоматически позаботится о закрытии открытых элементов и, наконец, о закрытии самого документа, нет необходимости делать это самостоятельно. Что касается механизма для потоковой передачи узлов от входа к выходу:

• Поскольку мы вынуждены использовать API курсора из-за проверки, мы должны использовать XSLT для передачи узла и его элементов в выходные данные. XSLT имеет несколько шаблонов по умолчанию, которые будут вызываться, если вы не укажете XSL специально. В этом случае он преобразует входной сигнал в заданный выходной.
• Необходим пользовательский FragmentXMLStreamWriterWrapper , я задокументировал это в JavaDoc. Эта оболочка снова обернута в AvoidDefaultNsPrefixStreamWriterWrapper . Причина последнего заключается в том, что шаблон XSLT по умолчанию не распознает пространство имен по умолчанию в нашем исходном документе. Подробнее об этом через минуту (или поиск AvoidDefaultNsPrefixStreamWriterWrapper).
• Используемый вами преобразователь должен быть внутренней версией Oracle JDK. Там, где мы инициализируем преобразователь, мы непосредственно ссылаемся на экземпляр внутреннего TransformerFactory: com.sun.org.apache.xalan.internal.xsltc.trax.TransformerFactoryImpl, который затем создает правильный преобразователь: transformer = new TransformerFactoryImpl (). NewTransformer ();Обычно вы будете использовать TransformerFactory.newInstance () и использовать преобразователь, доступный в пути к классам. Однако парсеры и преобразователи могут устанавливать себя, предоставляя сервисы META-INF /. Если другой преобразователь (например, Xalan по умолчанию, а не перепакованная версия JDK) окажется в пути к классам, преобразование завершится неудачно. Причина в том, что, по-видимому, только внутренняя версия JDK может преобразовывать StAXSource в StAXResult.
• Преобразователь фактически позволяет нашему XMLStreamReader продолжать работу в процессе итерации. Таким образом, после обработки элемента данных курсор считывателя теоретически будет готов к следующему элементу данных. В теории это так, поскольку следующий тип события может быть пробелом, если ваш XML отформатирован. Таким образом, все еще могут потребоваться некоторые итерации для xmlStreamReader.next () в нашем цикле while, прежде чем следующий элемент Data будет фактически готов.

В результате мы имеем 3 выходных файла, каждый из которых соответствует исходной схеме, каждый из которых имеет 2 элемента данных:

Чтобы разделить XML-файл размером ~ 30 ГБ (я говорю о моем исходном XML-документе назначения с более сложной структурой, а не о демонстрационном XSD, используемом здесь) на части ~ 500 МБ с проверкой, это заняло около 25 минут. Чтобы проверить использование памяти, я намеренно установил Xmx на 32 МБ. Как вы можете видеть на графике, потребление памяти очень низкое и нет накладных расходов GV:

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

В моем реальном сценарии входной XML не имел связанных с ним пространств имен, и я уверен, что никогда не будет. Вот почему я придерживаюсь этого решения. В демоверсии здесь есть единственное пространство имен, и это уже начинает делать настройку более хрупкой. Проблема не в StAX: обрабатывать пространства имен с помощью StAX довольно просто. Вы можете решить использовать пространство имен по умолчанию (при условии, что ваша Схема имеет значение elementFormDefault = qualified), соответствующее целевому пространству имен Схемы, и, возможно, объявить некоторые префиксные пространства имен для, возможно, других пространств имен, которые импортируются в Схеме. Проблемы начинаются (как вы уже могли заметить), когда XSLT начинает мешать выходному потоку. Очевидно, он не проверяет, какие пространства имен уже определены или что-то еще происходит.

В результате они серьезно загромождают документ, переопределяя существующие пространства имен с другими префиксами или сбрасывая пространство имен по умолчанию и другие вещи, которые вам не нужны. Вероятно, нужен XSL, если вам нужно больше манипулировать пространством имен, чем шаблон по умолчанию. XSLT также будет вызывать исключения, если во входном документе используются пространства имен по умолчанию. Он попытается зарегистрировать префикс с именем «xmlns». Это недопустимо, поскольку xmlns зарезервировано для указания пространства имен по умолчанию, которое нельзя использовать в качестве префикса. Исправление, которое я применил для этого теста, заключалось в том, чтобы игнорировать любой префикс, который является «xmlns», и игнорировать добавление целевого пространства имен в сочетании с префиксом xmlns (именно поэтому у нас есть AvoidDefaultNsPrefixStreamWriterWrapper).Префикс и пространство имен должны совпадать в AvoidDefaultNsPrefixStreamWriterWrapper, потому что если у вас будет входной документ без пространства имен по умолчанию, но с префиксами (например, <bigxml: BigXmlTest xmlns: bigxml = «http: // ….»> <bigxml : Header ….) тогда вы не можете игнорировать добавление пространства имен (тогда комбинация будет целевым пространством имен с префиксом «bigxml»), поскольку это даст только префиксы для элементов данных без привязки к ним пространств имен, например:префикс), поскольку это даст только префиксы для элементов данных без привязки к ним пространств имен, например:префикс), поскольку это даст только префиксы для элементов данных без привязки к ним пространств имен, например:

<?xml version='1.0' encoding='UTF-8'?>
<BigXmlTest xmlns="http://www.error.be/bigxmltest">
 <Header>
  <SomeHeaderElement>Something something darkside</SomeHeaderElement>
 </Header>
 <Content>
  <bigxml:Data>Data1</bigxml:Data>
  <bigxml:Data>Data2</bigxml:Data>
 </Content>
</BigXmlTest>

public class AvoidDefaultNsPrefixStreamWriterWrapper extends XMLStreamWriterAdapter {
...

 @Override
 public void writeNamespace(String prefix, String namespaceURI) throws XMLStreamException {
  if (defaultNs.equals(namespaceURI) && "xmlns".equals(prefix)) {
   return;
  }
  super.writeNamespace(prefix, namespaceURI);
 }

 @Override
 public void setPrefix(String prefix, String uri) throws XMLStreamException {
  if (prefix.equals("xmlns")) {
   return;
  }
  super.setPrefix(prefix, uri);
 }

while (xmlEventReader.hasNext()) {
   XMLEvent event = xmlEventReader.nextEvent();

   if (event.isStartElement() && event.asStartElement().getName().getLocalPart().equals(CONTENT_ELEMENT)) {
    event = xmlEventReader.nextEvent();

    while (!(event.isEndElement() && event.asEndElement().getName().getLocalPart()
      .equals(CONTENT_ELEMENT))) {

     if (dataRepetitions != 0 && event.isStartElement()
       && event.asStartElement().getName().getLocalPart().equals(DATA_ELEMENT)
       && dataRepetitions % 2 == 0) { // %2 = just for testing: replace this by for example checking the actual size of the current
               // output file
      xmlEventWriter.close(); // Also closes any open Element(s) and the document
      xmlEventWriter = openOutputFileAndWriteHeader(++fileNumber); // Continue with next file
      dataRepetitions = 0;
     }
     // Write the current event to output
     xmlEventWriter.add(event);
     event = xmlEventReader.nextEvent();

     if (event.isEndElement() && event.asEndElement().getName().getLocalPart().equals(DATA_ELEMENT)) {
      dataRepetitions++;
     }
    }
   }
  }