Комментарии 12
так как попытка загрузить в базу данных xml-документ 10-мегабайтного объёма, приводила к "подвисанию" на несколько часов
Из того что вы написали получается вы считаете проблемой что xml-документ 10-мегабайтного объёма очень долго парсится- раскладывается в таблицы, интересно почему вас не беспокоит сколько времени этот xml-документ 10-мегабайтного объёма создается (вы об этом не упоминаете по крайней мере). Мне кажется искать проблему надо на стороне его создания в первую очередь.
Вопрос о том как и почему данные накапливаются в промежуточном формате не рассматривали?
Я рассматриваю проблему на стороне подсистемы, осуществляющей хранение и обработку. Реализованное мною решение не нуждается в накоплении чего-либо в промежуточных форматах. Сохранение в базу данных - поточная процедура, работающая с той производительностью сохранения, которую может предоставить реляционная база данных. Хранение иерархических данных осуществляется в трёх таблицах (документы, узлы документов и связи между ними).
Вопрос создания xml-документа чаще всего лежит на стороне бизнес-потребности и универсальный инструмент хранения/обработки должен с максимально возможной производительностью работать независимо от размеров данных, которые в него загружают.
Мне товарищ рассказывал как он решил подобные проблемы примерно 20 (!) лет назад для системы хранения анализа билинговых данных (слежение за израсходованным оплаченным ресурсом по сотовой связи), тоже говорил что один файл данных загружался целый рабочий день в базу данных. Он как раз применил XML и стандартную виндузовую длл-ку для его парсинга, трансформаций, запросов, ... (XML, XSLT, XML Schema) с тех пор все летает. Он тогда гордился что смог сократить один из пяти (кажется) серверов из поставки оборудования под эти дела.
Я к тому что не надо пытаться написать свой XSLT процессор, XML парсер, все уже есть и работало уже 20 лет назад. Эта длл-ка бесплатная даже под виндос.
В некоторой части соглашусь - писать велосипеды пустая трата времени, но я уверен, что данное решение будет оптимальным для описанного мною класса проблем. Тем более, что это не отдельно стоящий парсер, а инструмент, превращающий реляционную базу данных в эффективно работающее документоориентированное хранилище. Возможность выполнять любые иерархические запросы с той же производительностью, что и реляционные запросы к плоским таблицам, позволяет упростить решение очень многих бизнес-задач.
<старыйпенсионер>
Приятель после универа в 9х пошел работать в банк (менатеп?). Через много лет , работая уже в телекоме и перебравшись в Москоу вспоминал. На первом этапе, когда он поступил на работу, абс-ка была написана на мумпсе (MUMPS, M-system). Все работало как часики, своя терминалка алфавитно-цифровая, ничего не виснет, откат/восстановление занимал минуты. Затем началась реорганизация. Привезли какие-то дорогущщие сервера под *nix, развернули сервер БД, установили новую абс-ку. Количество сбоев увеличилось на порядок, время простоя требуемого для восстановления/отката и устранения последствий еще больше. И так несколько итераций с переменным успехом (успех - то что количество проблем не увеличилось). Одно слово - прогресс....
</старыйпенсионер>
Одно слово - прогресс....
да, к сожалению, прогресс особенно заметен в развитии возможностей пудрить мозги.
Но это общие рассуждения, это не к статье.
По статье, я, например, не понял, где же описание или какая то основопологающая идея которая описывает
инструмент, превращающий реляционную базу данных в эффективно работающее документоориентированное хранилище
Здесь - В 2006-м году корпорацией IBM был опубликован интересный документ.
Документ действительно интересный, и было бы интересно узнать (и наверно обсудить) что, конкретно вы (у вас), подчерпнули-реализовали из этого proposal ("пропозола"), без этого смысл написания вашей статьи как то теряется. По крайней мере мне так кажется.
Если брать раздел "5.1 A Purely Relational Implementation", то он реализован полностью. Правда я подходил к этому документу как к описанию метода и структура хранения, собственно машина формирования запросов, несколько видоизменены, но основной подход полностью соответствует "proposal-у". Видоизменения вызваны тем, что я планирую довести этот проект до состояния, когда можно сохранять в базе данных любые соответствующие спецификациям xml-документы с учётом эволюции описывающих их xsd-схем (и сами схемы тоже), строить на полном множестве всех документов любые запросы, соответствующие спецификации XPath 3.1 и связывать отдельные узлы документов с НСИ и JPA-сущностями любых бизнес-доменов.
Было бы очень любопытно узнать в чём Вы видите смысл этой статьи?
Смысл этой статьи, как и любой другой, наверно и как мне кажется, найти заинтересованных людей по теме, и обсудить с ними свое понимание проблемы, технологии, ... а также достижения, результаты
Наверно, близко к тому чтобы проверить себя, проверить актуальность темы, решения, технологии, ... того что описано. Реклама своих достижений то же из списка положительных смыслов, как мне кажется.
Как я участвовал в создании информационных систем для медицины