Задача сравнить два XML файла. Размеры каждого порядка 2гиг.
структура
<root>
<doc>
<field name="p1"><[!CDATE[ejfghkenx]]></fiels>
...
<field name="p30"></field>
</doc>
</root>
сравнение по всем полям.
Одно из полей уникальное с типом int! для каждого <doc>, но сама XML не отсортирована по этому полю.
Короче
1, нужна идея вообще.
2, может есть мысли как отсортировать в промежуточный файл?
Здравствуйте, Dimas Owl, Вы писали:
DO>Задача сравнить два XML файла. Размеры каждого порядка 2гиг. DO>структура DO><root> DO><doc> DO><field name="p1"><[!CDATE[ejfghkenx]]></fiels> DO>... DO><field name="p30"></field> DO></doc> DO></root>
DO>сравнение по всем полям.
DO>Одно из полей уникальное с типом int! для каждого <doc>, но сама XML не отсортирована по этому полю.
DO>Короче DO>1, нужна идея вообще. DO>2, может есть мысли как отсортировать в промежуточный файл?
Идея такая что плохой дизайн.
Учти я впервые это сказал здесь.
Здравствуйте, Dimas Owl, Вы писали:
DO>Задача сравнить два XML файла. Размеры каждого порядка 2гиг. DO>структура DO><root> DO><doc> DO><field name="p1"><[!CDATE[ejfghkenx]]></fiels> DO>... DO><field name="p30"></field> DO></doc> DO></root>
DO>сравнение по всем полям.
DO>Одно из полей уникальное с типом int! для каждого <doc>, но сама XML не отсортирована по этому полю.
DO>Короче DO>1, нужна идея вообще. DO>2, может есть мысли как отсортировать в промежуточный файл?
Ну я так понял парсер это дело подымает и на нехватке памяти не падает.
Может попробуете все это безобразие отразить на файловую систему?
Узлы — директории, аттрибуты — файлы. А для сравнения двух директорий тулзовин полно.
Или опять же — если возникла задача отсортировать — сделать обратное преобразование, но уже отсортированое — не проблема
В любом случае — выложите пожалуйста ответ — я занимаюсь близкими вещами — авось пригодится когда
DO>Короче DO>1, нужна идея вообще. DO>2, может есть мысли как отсортировать в промежуточный файл?
Если структура xml'я простая (как в примере), то есть вариант записать содержимое xml'ей (элементов field, в данном случае) в две таблицы в базе данных. А разницу потом получать при помощи SQL запросов.
Здравствуйте, Dimas Owl, Вы писали:
DO>Была и такая мысль! но это полмиллинона файлов (500 000 объектов <doc>)! как-то даже и не знаю!
Если Вам тока сравнить правильность работы — проще протого — пощитайте контрольную сумму всех значимых элементов. Но не в отдельности а иерархии. Поясню.
<root>
<node attr="value">Bla-bla
</node>
</root>
Для attr считаете контрольную сумму для строки вида "<root><node>attr=value", для "Bla-Bla" — "<root><node>[Bla-Bla]" и т.д.
В общем придумать какой-то унифицированый формат для уникального отображения каждого элемента. И да! Обязательно включать в это отображение упомянутый id
Как мысля?
D>Если структура xml'я простая (как в примере), то есть вариант записать содержимое xml'ей (элементов field, в данном случае) в две таблицы в базе данных. А разницу потом получать при помощи SQL запросов.
Насколько мне известно все современные субд (MSSQL по крайней мере) умеют понимать в качествене исходных данных xlm и засовывать его в таблицу и выплевывать данные опять же в xml.
А проще сразу взять объектно-ориентированные СУБД — типа Cache — у них поддрежка xml родная — т.е. у тебя эти два файла практически будут двумя базами — и дальше запросами сравнить.
Здравствуйте, Dimas Owl, Вы писали:
DO>Задача сравнить два XML файла. Размеры каждого порядка 2гиг. DO>структура DO><root> DO><doc> DO><field name="p1"><[!CDATE[ejfghkenx]]></fiels> DO>... DO><field name="p30"></field> DO></doc> DO></root>
DO>сравнение по всем полям.
DO>Одно из полей уникальное с типом int! для каждого <doc>, но сама XML не отсортирована по этому полю.
DO>Короче DO>1, нужна идея вообще. DO>2, может есть мысли как отсортировать в промежуточный файл?
На мой взгляд, единственный разумный способ таков — отсортировать, как Вы верно написали, в промежуточный файл используя линейный алгоритм сортировки — он возможен поскольку у Вас есть уникальное поле типа int. Потом уже идти по двум отсортированным файлам и сравнивать записи. Итого все это займет большое, но линейное время.
Линейную сортировку можно сделать, например, вот так (bucket sort):
1. Создаете 256 временных файлов.
2. Читаете ваши <doc> по порядку и смотрите на младший байт в ID (то самое поле int).
3. Записываете <doc> в соответствующий файл.
4. Пройдя весь исходный файл, сливаете все временные файлы — сначала все <doc> и нулевого, потом из первого, и т.д.
5. Повторяете ту же операцию для 2-го, 3-го и 4-го байта в ID, в порядке увеличения значимости.
Здравствуйте, Young, Вы писали:
Y>Здравствуйте, dshe, Вы писали:
D>>Если структура xml'я простая (как в примере), то есть вариант записать содержимое xml'ей (элементов field, в данном случае) в две таблицы в базе данных. А разницу потом получать при помощи SQL запросов.
Y>Насколько мне известно все современные субд (MSSQL по крайней мере) умеют понимать в качествене исходных данных xlm и засовывать его в таблицу и выплевывать данные опять же в xml.
Y>А проще сразу взять объектно-ориентированные СУБД — типа Cache — у них поддрежка xml родная — т.е. у тебя эти два файла практически будут двумя базами — и дальше запросами сравнить.
Здравствуйте, BlackHeretic, Вы писали:
BH>Здравствуйте, Dimas Owl, Вы писали:
DO>>Была и такая мысль! но это полмиллинона файлов (500 000 объектов <doc>)! как-то даже и не знаю!
BH>Если Вам тока сравнить правильность работы — проще протого — пощитайте контрольную сумму всех значимых элементов. Но не в отдельности а иерархии. Поясню.
BH><root> BH> <node attr="value">Bla-bla BH> </node> BH></root>
BH>Для attr считаете контрольную сумму для строки вида "<root><node>attr=value", для "Bla-Bla" — "<root><node>[Bla-Bla]" и т.д.
BH>В общем придумать какой-то унифицированый формат для уникального отображения каждого элемента. И да! Обязательно включать в это отображение упомянутый id BH>Как мысля?
Была такая мысля Даже начал воплощать.
Прохожусь парсером
создаю объект для узла
вычисляю hashCode для объекта (=вычисляю hashCode для каждого элемента объекта), алгоритм взял в расчудесной книге Блоха. И уткнулся в расчет hashCode для строки. Это то как сделать.
Короче, что Вы имеете ввиду и как расчитать контрольную сумму для "Bla-Bla".
Здравствуйте, Dimas Owl, Вы писали:
DO>Здравствуйте, BlackHeretic, Вы писали:
BH>>Здравствуйте, Dimas Owl, Вы писали:
DO>>>Была и такая мысль! но это полмиллинона файлов (500 000 объектов <doc>)! как-то даже и не знаю!
BH>>Если Вам тока сравнить правильность работы — проще протого — пощитайте контрольную сумму всех значимых элементов. Но не в отдельности а иерархии. Поясню.
BH>><root> BH>> <node attr="value">Bla-bla BH>> </node> BH>></root>
BH>>Для attr считаете контрольную сумму для строки вида "<root><node>attr=value", для "Bla-Bla" — "<root><node>[Bla-Bla]" и т.д.
BH>>В общем придумать какой-то унифицированый формат для уникального отображения каждого элемента. И да! Обязательно включать в это отображение упомянутый id BH>>Как мысля?
DO>Была такая мысля Даже начал воплощать. DO>Прохожусь парсером DO>создаю объект для узла DO>вычисляю hashCode для объекта (=вычисляю hashCode для каждого элемента объекта), алгоритм взял в расчудесной книге Блоха. И уткнулся в расчет hashCode для строки. Это то как сделать. DO>Короче, что Вы имеете ввиду и как расчитать контрольную сумму для "Bla-Bla".
