Как/Можно ли использовать linq для xml для запроса огромных xml файлов с разумным потреблением памяти?

Я не много сделал с linq для xml, но все примеры, которые я видел, загружают весь XML-документ в память.

Что делать, если файл XML, скажем, 8 ГБ, и у вас действительно нет возможности?

Моя первая мысль - использовать XElement.Load Method (TextReader) в сочетании с экземпляром FileStream Class.

ВОПРОС: будет ли это работать, и это правильный способ подойти к проблеме поиска очень большого XML файла?

Примечание: высокая производительность не требуется.. Я пытаюсь получить linq в xml, чтобы в основном выполнять работу с программой, которую я мог бы написать, которая проходит через каждую строку моего большого файла и собирает, но поскольку linq является "loop centric" Я ожидаю, что это будет возможно....

Ответ 1

Использование XElement.Load загрузит весь файл в память. Вместо этого используйте XmlReader с функцией XNode.ReadFrom, где вы можете выборочно загружать заметки, найденные XmlReader, с помощью XElement для дальнейшей обработки, если вам нужно. MSDN имеет очень хороший пример: http://msdn.microsoft.com/en-us/library/system.xml.linq.xnode.readfrom.aspx

Если вам просто нужно выполнить поиск в документе xml, достаточно только XmlReader и не будет загружать весь документ в память.

Ответ 2

Габриэль,

Чувак, это не совсем ответ на ваш ФАКТИЧЕСКИЙ вопрос (как читать большие документы xml с помощью linq), но вы можете проверить мой старый вопрос Лучший способ анализа больших XML-документов в C-Sharp. Последний "ответ" (по времени) был "запиской для себя" о том, что НАСТОЯЩЕЕ РАБОТАЕТ. Оказывается, что гибридный документ-XmlReader и doclet-XmlSerializer быстрый (достаточно) и гибкий.

НО обратите внимание, что я имел дело с документами до 150 МБ. Если вы ДЕЙСТВИТЕЛЬНО должны обрабатывать документы размером до 8 ГБ? то я думаю, вы, вероятно, столкнетесь со всеми видами проблем; включая проблемы с обработкой O/S LARGE_FILE ( > 2 ГБ)... в этом случае я настоятельно рекомендую вам сохранять вещи как-примитивные как можно... и XmlReader максимально примитивен (и самый быстрый в соответствии с моим тестированием ) XML-парсер, доступный в пространстве имен Microsoft.

Кроме того: я только что заметил запоздалый комментарий в моей старой теме, предлагая, чтобы я просмотрел VTD-XML... У меня было быстрый взгляд на это сейчас... Это "выглядит многообещающим", даже если автор, похоже, заключил контракт с терминалом FIGJAM. Он утверждает, что он будет обрабатывать документы объемом до 256 ГБ; на что я отвечаю: "Да, ты проверил это? В какой среде?" Похоже, он должен работать, хотя... Я использовал эту же методику для реализации "гиперссылок" в текстовой справочной системе; назад до HTML.

В любом случае удачи в этом и вашего общего проекта. Приветствия. Кит.

Ответ 3

Я понимаю, что этот ответ можно считать невосприимчивым и, возможно, раздражающим, но я бы сказал, что если у вас есть XML файл размером 8 ГБ, то по крайней мере некоторые из того, что вы пытаетесь сделать в XML, должны выполняться посредством файловой системы или базы данных.

Если у вас есть огромные куски текста в этом файле, вы можете сохранить их как отдельные файлы и сохранить метаданные и имена файлов отдельно. Если вы этого не сделаете, у вас должно быть много уровней структурированных данных, возможно, с большим повторением структур. Если вы можете решить, что считается индивидуальной "записью", которая может быть сохранена как меньший XML файл или в столбце базы данных, вы можете структурировать свою базу данных на основе уровней вложенности выше этого. XML отлично подходит для небольших и грязных, он также хорош для довольно неструктурированных данных, поскольку он является самоструктурированным. Но если у вас есть 8 ГБ данных, которые вы собираетесь делать с чем-то значимым, вы должны (обычно) быть в состоянии рассчитывать на какую-то предсказуемую структуру где-то в ней.

Хранение XML (или JSON) в базе данных, а также поиск и поиск как для записей XML, так и внутри XML хорошо поддерживаются в настоящее время как средствами SQL, так и парадигмой NoSQL.

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