分析（数十万）XML文件

Question

我有一个应用程序，它将为它处理的每个搜索查询生成一个日志条目（来自Solr），这样我就可以为我的搜索引擎计算某些统计信息。例如，没有结果的查询数，平均命中数等等。现在我想知道如何最好地执行此分析。负荷估计为每天高达数万次搜索，并在一周内生成统计数据。换句话说，我正在寻找计算最多十万个XML文件的统计数据的最佳方法。

这个过程将由Apache Camel控制，我现在认为XQuery是解决这个问题的最佳选择。由于我还在努力建立模式，所以我无法进行任何真实世界的测试，所以我想在深入研究之前就最佳方法获取一些意见。有些问题：

• XQuery可以处理这么多文件，还是需要使用XSLT将它们全部转换为单个文档？
• XQuery是否适合这项工作？在我看来，它比使用高级编程语言更有效率，而XSLT太低级了。
• 一种替代方法可能是在Apache Lucene / Solr中索引这些查询。这会更有效吗？
• 我可以将这些XML文件存储在文件系统中吗？或者我需要将它们加载到XML数据库中吗？ （我不熟悉。）

Answer 1

XSLT 2.0或XQuery 1.0原则上都可以处理这个问题，但性能取决于实际的卷和查询的复杂性。通常，（我知道这听起来很平庸）XSLT在转换方面更胜一筹（从每个源文档生成新文档），而XQuery在查询方面更胜一筹（从每个源文档中提取少量信息）。将所有小文档合并为一个大文档没有特别的意义。我还要说，将它们放入数据库并没有多大意义，除非（a）你真的需要提供交叉索引，或者（b）你将在一段时间内重复使用这些文件。

Answer 2

问题的相应顺序答案：

• 是的，XQuery可以使用集合处理无限数量的文件，看看fn:collection()函数
• “正确的工具”是一个非常主观的问题并且值得商榷，因此它并不适合SO。但是，如果您想使用XML文档，XQuery是一个明显的选择，因为它完全是为此而设计的。但当然这也取决于其他因素，例如：你的技能
• 肯定会有一个指数加快这项工作。如果真的有必要取决于许多因素，例如文件的大小和预期的工作量。这里很难给出一个实际的答案，但作为一般规则，索引的东西总是一个好主意。但是，如果您经常更新，维护索引的成本可能会很高。很难判断您的应用程序是否会从中受益，因为它取决于工作负载，预期读写次数以及更多因素
• 我非常不建议只将它们存储在文件系统中。在您要求在Apache Lucene / Solr中索引它们之前，为什么不使用XML数据库对它们进行索引？如果你有数十万个XML文件并将它们存储在文件系统中，那么处理它们的速度很可能非常慢。这听起来非常像XML数据库的工作。那里有不同的内容，例如MarkLogic（商业），eXist（开源）或BaseX（开放源代码）等等。

Answer 3

他们 是否采用XML格式？我非常强烈地探索将这些统计信息加载到某种数据库中。如果信息的字段/类别是常规的，则为普通数据库;如果不是，则为无模式NoSQL数据库之一。这将使得推导统计数据变得更加容易。

如果已记录的标准可能发生变化，您甚至可以使用具体模式或动态字段将其加载回Solr（单独的核心）。