我们正在寻求开发一个报告应用程序，该应用程序报告存储在大量XML文件中的数据。〜3,000,000个文件的大小从7KB到5MB（每个文件都符合同一模式）。我猜想将大约有大约200GB的XML。我正在查看许多开源XML数据库（SEDNA，BASEX和ANTAVEN-DB），我不确定这些系统的扩展如何，我在此处阅读了这三个数据库的比较。这就是我对可伸缩性的关注。
有关我们要做的事情的一些详细信息：我们不会更改任何XML文件中的数据，并且每天都会添加新文件。由于我们关心报告查询性能对我们很重要，并且添加和索引新文件所需的时间对我们来说并不是一个重点。
我想知道是否有人在类似尺度上使用这些系统有经验？我已经查看了Basex统计页面，并查看了一些相当大的XML实例，但没有提及性能。
我们不需要开源产品，Marklogic系统看起来可以很好地适合该账单，但是我很好奇开源产品做了什么。
我认为不可能用yes或no回答您的问题。从您给出的小细节中陈述有关性能的任何内容。
性能通常基于您要执行的查询和数据的分布。更不用说，您认为是"可接受的"。
在您引用的论文中，有趣的是，他们声明他们无法获得新范围索引存在的2.2预览。当然，没有这些，他们的表现会更糟。最后，他们还指出，他们将选择SEDNA，因为他们可以克服SEDNA的问题，这对我来说尚不清楚为什么这样，即他们有可以与Sedna一起使用的C 开发人员，但他们没有Java Devs可以使用存在还是基本？最后，他们使用用于测试的Java的版本相当古老，而存在的下一个版本（3.0）仅支持Java 8和更新。
如果您无法将200GB数据存储到BaseX，存在或SEDNA，但是在不知道您的数据和要执行的查询的情况下，我会感到惊讶，我无法对查询性能发表评论。
我认为您最好以与链接的文章不同的方式对一个或全部进行小型试验。
只想分享我在这个主题上的经验。我的经验仅限于较小的数据集 - 大约约50K文档的总尺寸约为1GB。为此，我们使用SEDNA XML DB。我们不会更改文档，而是在发生更改时覆盖现有文档，并且有很多只读的Xqueries，包括大报告。
不久，我的看法是，除非您找到将其复制到另一台服务器用于阅读的服务器的方法，否则SEDNA对您不起作用。在执行一些长期的报告Xqueries时，我遇到了与收集锁相关的重大性能问题。据我所知，Sedna没有提供复制功能，但您可能可以在Sedna上采用一些解决方案。例如，快速谷歌搜索揭示了该领域的一些研究。您可以尝试在Sedna邮件列表上询问。除其他缺点外，缺乏Xquery 3.0支持，并且似乎冻结了进一步的发展。但是，在邮件列表中，支持仍然非常活跃。
我也有ANDOM-DB的经验，但我将其更多地用作XML处理和管道平台，而不是XML存储。与缩放有关，它看起来仍然有些有前途。尽管我没有使用其复制功能，但文档中提到了它们。我建议您也尝试在邮件列表上搜索/询问。