【问题标题】:Exact phrase search using lucene without increasing number of fields在不增加字段数量的情况下使用 lucene 进行精确的短语搜索
【发布时间】:2012-01-02 10:38:52
【问题描述】:

对于短语搜索,我们只想在完全匹配的情况下显示结果(不忽略停用词)。如果是非短语搜索,即使单词的根形式匹配等,我们也可以很好地显示结果。

我们目前通过standardTokenizer、StopFilter、PorterStemFilter 和LowerCaseFilter 传递我们的数据。因此,当用户想要搜索“密码管理”时,搜索会显示包含“密码管理”的结果。

如果我删除 StemFilter,那么我将无法匹配非短语查询的词根形式。我在考虑是否应该将相同的数据索引为文档中两个字段的一部分。

我在Different indexing and search strategies on same field without doubling index size? 也问过同样的问题。然而,办公室里的人们对于将相同的数据作为两个字段的一部分进行索引并不高兴。 (我们目前在 lucene 文档中有大约 20 个文本字段)。有什么方法可以使用 TokenFilters 来支持我上面列出的这两种情况?

说,对于 StopFilter,进行更改,使其同时发出输入标记和 ? (对于忽略的单词)具有相同的位置增量。与 StemFilter 类似,它发出具有相同位置增量的输入标记和词干标记。基本上输入和输出标记(甚至被忽略的标记)具有相同的位置。

继续采用这种方法是否安全?有没有其他人遇到过这里列出的要求?是否有现成的过滤器可以做类似于我在我的方法中提到的事情?

谢谢

【问题讨论】:

    标签: full-text-search lucene text-analysis exact-match


    【解决方案1】:

    我不明白您所说的“输入和输出令牌”是什么意思。您是否将数据存储了两次——一次是有词干的,一次是非词干的?

    如果您不存储两次,我认为您的方法行不通。假设存储的单词是jumping,他们搜索jumped。您的查询解析器可以发出jumpjumped,但它仍然不会匹配jumping,除非您将值存储为jump

    如果您要将值存储一次作为词干,一次存储为非词干,那么为什么不将其存储在两个字段中呢?这样您就不必处理奇怪的标记器更改。

    【讨论】:

    • @Xodarp:是的,计划是在不使用两个字段的情况下存储两次(只是为了在将应用程序查询语言转换为 Lucene 查询时简化事情)。你知道这是否是搜索引擎的实现方式吗?谢谢
    • 大多数搜索引擎都认为存储便宜,延迟昂贵,因此它们确实倾向于采用冗余存储的方式。谷歌是否有多个字段(甚至是“字段”的概念)我不能说。
    • 我应该补充一点:如果您进行这些标记器更改,您将遇到各种突出显示等问题。请仔细考虑破坏 Lucene 的代码是否真的比翻译更容易。
    猜你喜欢
    • 2011-07-28
    • 2012-09-05
    • 1970-01-01
    • 2014-02-16
    • 1970-01-01
    • 2015-10-19
    • 2013-03-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多