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

Question

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

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

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

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

Answer 1

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

В ближайшее время, по моему мнению, Sedna не сработает для вас, если вы не найдете способ реплицировать его на другой сервер, который будет использоваться для чтения. У меня возникли серьезные проблемы с производительностью, связанные с блокировками коллекций с довольно умеренной нагрузкой на базу данных при выполнении некоторых долговечных отчетов XQueries. Насколько я знаю, Sedna не предлагает возможности репликации, но вы, вероятно, можете принять какое-то решение поверх Sedna. Например, быстрый поиск в google показал some research в этой области. Вы можете попробовать задать вопрос по адресу Sedna mailing list. Среди других недостатков - отсутствие поддержки XQuery 3.0 и, казалось бы, замороженная дальнейшая разработка. Однако поддержка по-прежнему довольно активна в списке рассылки.

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

Answer 2

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

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

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

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

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