Кто, чем и как обрабатывает XML-файлы большого объема ?

← →
Игорь Шевченко © (2012-11-01 13:15) [0]

По моему понимаю, польшой объем начинается от 100 мегабайт. Интересуют технологии и средства формирования, чтения, валидации по схеме.
Все это интересует применительно к Delphi, разумеется, XML-файлы нужно формировать, читать и валидировать программно.
msxml с использованием DOM на такого объема файлах потребляет негуманное количество ресурсов

← →
имя (2012-11-01 13:41) [1]

Удалено модератором

← →
jack128_ (2012-11-01 13:42) [2]

может чем поможет: http://forum.sources.ru/index.php?showtopic=81572

← →
Rouse_ © (2012-11-01 13:54) [3]

Точнее лучше вот так смотреть, чтоб не искать: http://forum.sources.ru/index.php?showtopic=81572&view=findpost&p=600614

← →
Игорь Шевченко © (2012-11-01 13:56) [4]

Rouse_ © (01.11.12 13:54) [3]

> http://forum.sources.ru/index.php?showtopic=81572&view=findpost&p=600614

"Тест 2. Файл размером 1,75 МБ."

> объем начинается от 100 мегабайт

← →
AV © (2012-11-01 14:18) [5]

а если просто?
oq1: TOraQuery;

S := DateTimeToStr(now);
oq1.Open;
oq1.SaveToXML("c:\11.xml");
S := S + " "+ DateTimeToStr(now);
mmo1.Lines.Add(s);

01.11.2012 14:15:44 - 01.11.2012 14:17:13
файл - 210 МБ

← →
DVM © (2012-11-01 14:22) [6]

> msxml с использованием DOM на такого объема файлах потребляет
> негуманное количество ресурсов

У MS есть и SAX парсер вроде бы.
http://support.microsoft.com/kb/311423/ru

← →
Игорь Шевченко © (2012-11-01 14:31) [7]

DVM © (01.11.12 14:22) [6]

Благодарю. Хотелось бы еще примеров :)

← →
DVM © (2012-11-01 15:05) [8]

> Игорь Шевченко © (01.11.12 14:31) [7]

> Хотелось бы еще примеров :)

У меня нету. Я не использовал его ни разу, только собирался. А примеров на MSDN есть, только они все VB и VC++
Вот например.
http://msdn.microsoft.com/en-us/library/ms994335.aspx

← →
Sergey Masloff (2012-11-01 15:15) [9]

DVM © (01.11.12 14:22) [6]
А SAX парсер (кстати это тот же msxml просто другой режим работы) как поможет в валидации и формировании? Это же просто обходчик выдающий сигналы при встрече с нодами.

По сабжу - к сожалению не помогу. С файлами 20-30 Мб msxml справлялся.
Сейчас все в оракле делаю, он тоже ресурсов жрет поэтому через isntr-substr режу на однотипные куски (а файл 200 Мб это скорее всего список чего-то более мелкого) а их уже валидирую и так далее. Получакется достаточно быстро

← →
Игорь Шевченко © (2012-11-01 15:19) [10]

Sergey Masloff (01.11.12 15:15) [9]

В формировании он вряд ли поможет, а вот в валидации вполне может помочь, загружая только необходимые части XML (это еще будет тестироваться, разумеется).

← →
Sergey Masloff (2012-11-01 15:23) [11]

А так он умеет по схеме проверять... Я и не знал :(
DVM © спасибо

← →
cobalt © (2012-11-01 15:43) [12]

Насчет валидации по схеме не скажу, а вот чтение 300 Мб файл TXMLDocument справляется, хотя и забирает под это от гига памяти.

← →
Медвежонок Пятачок © (2012-11-01 15:47) [13]

а я по схеме никогда не валидирую.
как-то не надобилось никогда.

PS юзать TXMLDocument для чтения - все равно что юзать TTable вместо TQuery

← →
cobalt © (2012-11-01 15:57) [14]

> Медвежонок Пятачок © (01.11.12 15:47) [13]
> PS юзать TXMLDocument для чтения - все равно что юзать TTable вместо TQuery
А что предлагаешь использовать взамен?

← →
Медвежонок Пятачок © (2012-11-01 16:43) [15]

IXMLDOMDocument(2)

То есть выбор узлов запросами, а не сугубо навигационный метод

← →
Пит (2012-11-01 18:13) [16]

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

Если следовать идеологии XML, то на самом деле ты вынужден распарсивать XML-код в такие структуры, что они обязаны жрать дикое количество памяти. То есть, 100 mb исходного xml будет жрать мегабайт 500-600 памяти, никак не меньше. А не повезет - так еще больше.

Особенно - если хочется формирования и валидации.

Поэтому хочется работать с таким - пиши своё узкоспециализированное решение. В реальности, обычно от всей возможности xml нужно пару процентов.

← →
Inovet © (2012-11-01 21:43) [17]

> [16] Пит (01.11.12 18:13)
> мы пришли к выводу, что невозможно использовать готовые XML движки для обработки больших xml-файлов.

Вот оно и есть. Возможность редактирования человеком в некоем простом текстовом редакторе отпадает, а для нетекстовойй работы фотмат не годится.

Сформировать любого размера - проблем нет, а вот читать эту лабуду при больших объёмах - есть проблемы.

← →
Inovet © (2012-11-01 21:45) [18]

> [17] Inovet © (01.11.12 21:43)

Да, по теме не подскажу.

← →
Dennis I. Komarov © (2012-11-01 21:48) [19]

> а вот читать эту лабуду при больших объёмах - есть проблемы.

Ну читать, проблем то нету, как ex(imp)ort вполне себе...

← →
Rouse_ © (2012-11-01 21:52) [20]

Проблема в том что XML в 200 метров может быть с одним узлом с бинарным блоком, или из миллиарда маленьких, коие хранить в памяти (ну допустим даж в двунаправленом списке) по 12 байт на узел + данные самого узла, что выльется в те-же гигабайты памяти. В прошлой моей задаче я с примерно такой-же задачей столкнулся (хранение и работа с деревьями) правда блобы были на несколько порядков больше, текущее дерево индексов в районе 9 гектаров...
Воть, лично я бы порекомендовал, если не требуется поддержка всех наворотов стандарта, реализовать собственный быстрый парсер

← →
имя (2012-11-01 22:20) [21]

Удалено модератором

← →
Dennis I. Komarov © (2012-11-01 22:30) [22]

Удалено модератором

← →
Rouse_ © (2012-11-01 22:52) [23]

> по 12 байт на узел + данные самого узла, что выльется в
> те-же гигабайты памяти.

Дабы было более понятно, я приведу годичную цитату с нашего внутреннего форума где мы запнулись как раз на больших обьемах мелких данных:

В новой версии ГСИ мы ввели поисковые индексы на базе токенов. Токен - это скажем так некое уникальное слово. Например если у нас есть миллион документов состоящих из трех слов "мама мыла раму" то в итоге у нас на руках будет всего три токена (по одному на каждое слово) и куча индексов, указывающих в каком документе тот или иной токен встречается. В результате (если исключить поиск по параграфам или по дистанции) список документов отбирается меньше чем за 10 миллисекунд. А засада вылезла как раз в количестве этих самих токенов. Мы для себя сделали 10 самых больших баз от 3 гигабайт до 300 мегабайт (т.е. 10 самых больших) и тестировали на них. И скорость и память - все нас устраивало. Пока не пришло время тестировать на полном комплекте баз (sik). А это как раз произошло за день как мы решили отдавать тот вариант финальной беты. Немного математики: мы тестировали на обьеме 5 с половиной гигобайта (реальный общий размер баз), остальные копеешные базы занимают примерно еще гигобайт все вместе. Мы и не предполагали, что в более меньших по объему базах, количество памяти, необходимое под хранение токенов практически идентично большим базам. И тут представьте наше удивление когда приложение просто банально перестает запускаться из-за того что закончилась память на компьютере! WTF!!! Все это из-за того, что большинство слов встречаются повсеместно и будут присутствовать практически в каждом документе, из-за чего количество токенов даже в маленькой базе будет практически идентично размеру большой (около 3 миллионов). А этот нюанс мы полностью пропустили!!! А теперь опять банальная математика. Если в каждой базе будет в среднем по 3 миллионов токенов (а это сейчас так и есть) и допустим что нам нужно хотя бы 4 байта для хранения каждого (в действительности требуется гораздо больше) то получается что для 200 баз нам нужно памяти 2 гигобайта и 288 мегобайт. Т.к. у современного приложения всего доступно для чтения от двух до трех гигобайт (наше умеет работать с тремя) то сами видите с какой проблемой мы столкнулись. Собственно, последнее время перебираем движок, пытаясь впихнуть невпихуемое...

← →
TUser © (2012-11-02 06:51) [24]

Я парсил самописным кодом (без классов, только указатели на record и New) 143 Мб. Это был узел, у которого 100 с чем-то тысяч детей. Работало, но тормозило. Мне не нужна была валидация.

← →
Sergey Masloff (2012-11-02 09:16) [25]

> Inovet © (01.11.12 21:43) [17]
> Сформировать любого размера - проблем нет, а вот читать
> эту лабуду при больших объёмах - есть проблемы.

Вот читать через SAX интерфейс вообще не проблема. Гигабайтные файлы.
Надо проверить как он валидацию для них делает

← →
jack128_ (2012-11-02 10:26) [26]

> Насчет валидации по схеме не скажу, а вот чтение 300 Мб
> файл TXMLDocument справляется, хотя и забирает под это от
> гига памяти.

сильно зависит от структуры файла. Для одного нашего формата он не смог и 60метровый файлик загрузить. сжирал 1.5гига и падал. Так что тут как повезет.

← →
Медвежонок Пятачок © (2012-11-02 13:09) [27]

В реальности, обычно от всей возможности xml нужно пару процентов.

Это как сказать.
Пример:
Пришел я в коллектив, где юзается система отчетов, встроенная в программу.
Там скриптовый язык, доступ к данным, работа с офисом и т.д.
В общем круто все.

Начал дизайнить отчеты и передизайнивать чужие.
Встретил кучу подпорочного нечитаемого слабоподдерживаемого кода, который там был в силу неразвитых структурных типов и однонаправленности датасетов.

Но тут вдруг оказалось, что в отчетах доступно OLE.
Я стал использовать Msxml2.DOMDocument, собирая в него нужные данные, с легкостью их доставал, мог фильтровать и т.д.
И уже по xml данным формировал сложные отчеты.

результат:
Объем необходимого кода упал от двух до трех раз.
Исчезли геморрои с индексными переменными строк в конструкциях типа
Зафигачь_Данные_На_Лист_Excel(1,1,"мапа");
Зафигачь_Данные_На_Лист_Excel(1,2,"мапа");
.....
Зафигачь_Данные_На_Лист_Excel(1,666,"любовь");
Исчезли дебильные циклы поиска-перебора закешированных ранее данных.
Исчезли повторные запросы-перезапросы к базе

Вот так-то так.

← →
Аббат Пиккола (2012-11-02 13:55) [28]

Я для быстрой разборки написал свой собственный примитивный парсер. Который создает FileStream, проходит его один раз, запихивая все в древовидную структуру, которую организовал на основе нескольких своих простых классов. Мне просто было лень изучать имеющиеся парсеры, поэтому я пошел таким путем. Так как круг задач был ограничен разбором "чисто текстовых" файлов и типы данных были заранее известны. Хранил все атрибуты как строки , а обращался за данными, в зависмости от типа (который знал заранее), методами AsInteger, AsString, AsDateTime, которыми снабдил свой класс TXMLNode, передавая в качестве параметра имя нужного атрибута. Разумеется, это кустарный подход. Но если бы у меня стояла задача быстро разбирать большие файлы заранее известных форматов, наверно, я бы опять пошел путем чего-нибудь самописного. По крайней мере в самописном парсере можно добиться максимума производительности, так как ради конкретной задачи можно чем-то ненужным пожертвовать.
Наверно для очень больших файлов хорош подход TUser © (02.11.12 06:51) [24], то есть вместо классов использовать тип record.

Все верно.
Когда голове работать лень, тогда работают пальцы по набивке индус-кода.

> [28] Аббат Пиккола (02.11.12 13:55)
> Но если бы у меня стояла задача быстро разбирать большие
> файлы заранее известных форматов, наверно, я бы опять пошел
> путем чего-нибудь самописного

Я тоже так думаю. Именно для заранее известных, в которых использутся эти самые 2% от всех возможностей формата.

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

← →
Пит (2012-11-02 16:26) [32]

> В реальности, обычно от всей возможности xml нужно пару
> процентов.
>
> Это как сказать.
> Пример:

> В реальности, обычно

Я показал, что бывает когда решаешь задачу как обычно
и что получается когда решаешь ее необычно.

или ты, пит, думаешь, что я хотел сказать, что я весь такой необычный и задачи мои сверх необычны?

← →
Пит (2012-11-02 21:38) [34]

нет, просто у тебя отсутствует логика.

Я говорил, что обычно вот так-то.

Ты пишешь - "это как сказать, ведь бывает и так-то".

Непонятно к чему ты это сказал, если я изначально показал, что бывает по разному, но обычно так-то.

А как на самом деле - знает топикстартер.

логика отсутствует у тебя.

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

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

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

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

Это если не зацикливаться на том, сколько процентов лично тебе положено использовать.

← →
Пит (2012-11-05 15:22) [36]

ты сейчас что-то предполагаешь. Типа люди используют XML на 2%, а надо бы больше. Я в отличии от тебя никого жизни учить не собираюсь, просто констатирую факты. Обычно возможности XML используют на пару процентов, я это вижу - я это озвучит. Это моя такая вот статистика. И я знаю, что бывает по-другому, но в целом я вижу, что xml как формат данных используют вот так. У тебя своя статистика ты хочешь сказать? По-моему, ты это не хочешь сказать.
Вот и собственно всё.

Ты начал разговор из серии, что "если бы..". Если бы люди были умнее, если бы они лучше знали, если бы, если бы. Может быть и если бы, то и xml бы на 90% использовался бы. А обычно это передать данные между двумя системами, чтобы тупо свои делимитеры не изобретать, вот и все. Даже валидация по XSD это уже редко где встречается, обычно там где это стало большим промышленным решением. А так "Ну давай короче я тебе в теге FIO буду фамилию имя отчество передавать, а в теге Job - должность". - "Оке".

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

> Даже валидация по XSD это уже редко где встречается

prove it

Пит, все что ты хочешь сказать - это то, что есть куча народу, которая на каждый чих ищет или создает собственные реализации того, что уже сто лет как есть.

недальше как на прошлой неделе встретил еще одного такого пита.
Ему нужно было посчитать хеш по sha-512.
Первое что он сделал - стал искать велосипедные реализации этого на паскале.
В то время как готовая реализация в винде сто лет лежит у него под носом

> Медвежонок Пятачок © (05.11.12 17:28) [38]

> Ему нужно было посчитать хеш по sha-512.
> Первое что он сделал - стал искать велосипедные реализации
> этого на паскале.
> В то время как готовая реализация в винде сто лет лежит
> у него под носом

Некоторые API от MS настолько замуденые, что зачастую проще написать свое, чем продираться сквозь десятки функций для выполнения простой вещи.
И кроссплатформенно будет.

Ага.
Но дело в том, что хеш на capicom это ровно четыре строки кода.
Создать объект,
Выставить нужный алгоритм
Вызвать метод Hash
Прочитать результат.

Кто, чем и как обрабатывает XML-файлы большого объема ? Найти похожие ветки