Масштабируемость баз данных XML с открытым исходным кодом

Мы стремимся разработать приложение для создания отчетов, которое сообщает о данных, хранящихся в большом количестве файлов XML. ~3 000 000 файлов размером от 7 КБ до 5 МБ (каждый файл соответствует одной и той же схеме). Я предполагаю, что будет около 200 ГБ XML. Я просматриваю ряд баз данных XML с открытым исходным кодом (Sedna, BaseX и eXist-db) и не уверен, насколько хорошо эти системы будут масштабироваться, я прочитал сравнение этих трех баз данных здесь. Отсюда и возникли мои опасения по поводу масштабируемости.

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

Мне интересно, есть ли у кого-нибудь опыт использования этих систем в подобных масштабах? Я просмотрел страницу статистики BaseX и увидел довольно большие экземпляры XML, но не упоминал о производительности. .

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


exist-db basex xml-database sedna
person David Harris    schedule 06.05.2015    source источник

Ответы (2)


arrow_upward
8
arrow_downward

Я думаю, что невозможно ответить на ваш вопрос ни yes, ни no. На самом деле невозможно что-либо сказать о производительности по тем мелким деталям, которые вы предоставили.

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

В документе, на который вы ссылались, интересно обратите внимание, что они заявляют, что не смогли заставить работать новые индексы диапазона в предварительной версии eXist 2.2. Конечно, без них они показали бы гораздо худшие результаты. Также в конце они заявляют, что выберут Sedna, поскольку они могут решить проблемы с Sedna, мне было непонятно, почему это было, т.е. есть ли у них разработчики C++, которые могут работать с Sedna, но у них нет разработчиков Java, которые может работать с eXist или BaseX? Наконец, версия Java, которую они использовали для тестирования eXist и BaseX, довольно старая, следующий выпуск eXist (3.0) будет поддерживать только Java 8 и новее.

Я был бы удивлен, если бы вы не могли хранить 200 ГБ данных в BaseX, eXist или Sedna, но, не зная ваших данных и типа запросов, которые вы хотите выполнить, я не могу комментировать производительность запросов.

Я думаю, вам лучше всего провести небольшую пробную версию одного или всех способов, не отличающихся от этой связанной статьи.

person adamretter    schedule 07.05.2015
comment
То, что автор проигнорировал новые индексы диапазонов eXist 2.2, было довольно важным предостережением. Я бы хотел, чтобы автор обратился за помощью в список рассылки eXist; настроить это тривиально. Также статья неоднократно была противоречивой; например, когда размер коллекции увеличивается, BaseX и Sedna остаются более или менее постоянными во времени, тогда как BaseX увеличивается линейно во времени (стр. 7). Жалко, что статья не вычитана. Тем не менее, статья представляет собой довольно тщательное исследование производительности одного пользователя/организации, и все три проекта должны отнестись к нему серьезно. - person Joe Wicentowski; 08.05.2015

arrow_upward
3
arrow_downward

Просто хочу поделиться своим опытом по этой теме. Мой опыт ограничен гораздо меньшими наборами данных - это примерно около 50 тысяч документов общим размером около 1 ГБ. Для этой цели мы используем Sedna XML DB. Мы не изменяем документы, а перезаписываем существующие документы, когда происходят изменения, и имеем множество XQueries только для чтения, включая большие отчеты.

Короче говоря, я считаю, что Sedna не будет работать для вас, если вы не найдете способ реплицировать ее на другой сервер, который будет использоваться для чтения. Я столкнулся с серьезными проблемами производительности, связанными с блокировками коллекции при довольно умеренной нагрузке на базу данных при выполнении некоторых длительных отчетов XQueries. Насколько я знаю, Sedna не предлагает возможности репликации, но вы, вероятно, можете внедрить какое-то решение поверх Sedna. Например, быстрый поиск в Google выявил некоторые исследования в этой области. Вы можете попробовать задать вопрос в списке рассылки Sedna. Среди других недостатков — отсутствие поддержки XQuery 3.0 и кажущаяся замороженность дальнейшей разработки. Тем не менее, поддержка все еще довольно активна в списке рассылки.

Также у меня есть некоторый опыт работы с eXist-db, но я использую его больше как платформу для обработки и конвейерной обработки XML, а не как хранилище XML. Тем не менее, это выглядит немного более многообещающе в отношении масштабирования. Хотя я не использовал его возможности репликации, они упоминаются в документы. Я также предлагаю вам попробовать поискать/спросить в списке рассылки.

person lagivan    schedule 07.05.2015