0

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

该过程将由 Apache Camel 控制，我目前认为 XQuery 将是解决这个问题的最佳选择。由于我仍在努力建立架构，因此我无法运行任何真实世界的测试，因此我想在深入研究之前就最佳方法获得一些意见。一些问题：

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

3 回答 3

3

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

于 2013-04-24T11:20:44.510 回答
2

按问题的相应顺序回答：

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

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

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

于 2013-04-24T19:07:52.590 回答