【问题标题】:Payload performance in LuceneLucene 中的负载性能
【发布时间】:2009-09-15 21:36:28
【问题描述】:

我知道网络上以及 SO 上有几个关于 Lucene 中的索引和查询性能的主题,但我还没有找到一个讨论是否(如果是,多少?)创建有效负载会影响查询性能...

这是场景......

假设我想要索引一组文档(从 100K 到 10M),并且每个文档都有一个我希望能够单独搜索的小节(或者可能排名更高,取决于是否在其中找到匹配项那个部分)。

我正在考虑向该小节中出现的任何术语添加有效负载(在索引期间),这样我就可以在查询时有效地做出决定。

有谁知道任何与使用有效载荷相关的性能问题,或者更好的是,您能否指出有关此主题的任何在线文档?

谢谢!

编辑:我很欣赏我的方案的替代解决方案,但如果我将来确实需要使用有效负载,是否有人对关于查询性能的原始问题有任何 cmet ?

【问题讨论】:

  • 看看 Compass (compass-project.org),它让这种在 Lucene 之上的高性能分层变得更加容易。
  • 感谢您的建议,我确实是今天下午才遇到 Compass,所以很高兴知道我可能走在正确的轨道上。如果我有任何运气,我会尽力报告!

标签: performance lucene payload


【解决方案1】:

教科书式的解决方案是将每个原始文档索引为两个字段:一个用于完整文档,另一个用于小节。您可以在索引期间或检索期间单独提升 subsection 字段。 话虽如此,您可以在此处阅读有关 Lucene 有效负载的信息:Getting Started with Payloads

【讨论】:

【解决方案2】:

您的用例与有效负载的用途不太相符——在我看来,任何有效负载信息都是多余的。

负载附加到文档中各个出现的术语,而不是文档/术语对。为了存储和访问有效负载,您必须使用文档中术语出现的偏移量。在您的情况下,如果您知道偏移量,您应该能够计算术语出现在哪个部分,而无需使用有效负载数据。

更广泛的问题是有效载荷对性能的影响。我的经验是,如果使用得当,payload 实现占用的空间更少,而且比我之前使用的任何解决方法都更快。对磁盘空间的最大影响将是您当前使用 Field.setOmitTermFreqAndPositions(true) 减小索引大小的任何位置。您将需要包含位置以使用有效负载,这可能会使索引更大。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2012-06-06
    • 2010-09-08
    • 1970-01-01
    • 1970-01-01
    • 2010-11-14
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多