电商网站开发定制,做名片用什么网站,创业做网站开发,网站seo搜索引擎的原理是什么在这篇博文中#xff0c;我们将讨论 complete suggester - 一种针对自动完成功能进行优化的 suggester#xff0c;并且被认为比我们迄今为止讨论的方法更快。
Completion suggester 使用称为有限状态转换器的数据结构#xff0c;该结构类似于 Trie 数据结构#xff0c;并且…
在这篇博文中我们将讨论 complete suggester - 一种针对自动完成功能进行优化的 suggester并且被认为比我们迄今为止讨论的方法更快。
Completion suggester 使用称为有限状态转换器的数据结构该结构类似于 Trie 数据结构并且针对更快的查找进行了优化。 这些数据结构存储在节点的内存中以实现更快的搜索。 与 edge-n-gram 和 search_as_you_type 一样这也通过使用我们提供的输入更新内存中的 FST 来完成索引时的大部分工作。
Elasticsearch 类型的一种特殊类型 —— complete用于实现它
PUT /movies
{mappings: {properties: {title: {type: completion}}}
}
映射还支持完成字段的 analyzer、search analyzer、max_input_length 参数。 分析器值默认为 simple analyzer它将输入小写并对任何非字母字符例如数字、空格、连字符等进行分词。完成类型上的分析器的行为与其他文本字段上的分析器不同。 经过分析后分词不能单独使用 - 它们根据输入文本中的顺序放在一起并插入到 FST 中。 此外我们无法在此方法中使用 _analyze 端点来测试我们的映射。 如果我们尝试这样做Elasticsearch 会抛出一个错误指出 “Cant process field [title], Analysis requests are only supported on tokenized fields”。
在索引文档时我们指定输入和可选的权重参数 -
POST /movies/_doc/1001
{title: [{input: Harry Potter and the Goblet of Fire,weight: 5},{input: Goblet of Fire,weight: 10}]
}POST /movies/_doc/1002
{title: {input: [Harry Potter and the Goblet of Fire,Goblet of Fire],weight: 2}
}
我们可以使用 input 参数为单个文档指定多个匹配项。 weight 参数控制搜索结果中文档的排名。 它可以针对每个 input 进行指定如上面的第一个文档1001中所示或者可以对所有 input 保持相同如第二个文档1002中所示。
使用 _search 端点的请求正文中的 suggest 子句查询建议字段。 在 ES 5.0 版本之前有一个单独的端点 - _suggest 用于 suggester。 互联网上的许多示例都使用 _suggest。 从版本 5 开始_search 端点本身也已更新以支持 suggester。
默认情况下Elasticsearch 返回整个匹配文档。 如果我们只对建议文本感兴趣我们可以使用 _source 选项并将其设置为“suggest”。 通过这种方式我们可以最大限度地减少磁盘获取和传输开销
GET /movies/_search?filter_path**.harry_suggest
{_source: title.input,suggest: {harry_suggest: {prefix: goblet of f,completion: {field: title}}}
}
上面命令返回的结果为
{suggest: {harry_suggest: [{text: goblet of f,offset: 0,length: 11,options: [{text: Goblet of Fire,_index: movies,_id: 1001,_score: 10,_source: {title: [{input: Harry Potter and the Goblet of Fire},{input: Goblet of Fire}]}},{text: Goblet of Fire,_index: movies,_id: 1002,_score: 2,_source: {title: {input: [Harry Potter and the Goblet of Fire,Goblet of Fire]}}}]}]}
}
Goblet of Fire 在建议中返回了两次因为我们已在两个文档中提供此文本作为输入。 这可以通过使用 skip_duplicates 选项来避免。
GET /movies/_search?filter_path**.harry_suggest
{_source: title.input,suggest: {harry_suggest: {prefix: goblet of f,completion: {field: title,skip_duplicates: true}}}
}
{suggest: {harry_suggest: [{text: goblet of f,offset: 0,length: 11,options: [{text: Goblet of Fire,_index: movies,_id: 1001,_score: 10,_source: {title: [{input: Harry Potter and the Goblet of Fire},{input: Goblet of Fire}]}}]}]}
} 警告当设置为 true 时此选项会减慢搜索速度因为需要访问更多建议才能找到前 N 个。 在 completion suggester 的情况下Elasticsearch 从第一个字符开始一次匹配文档一个字符在输入新字符时向前移动一个位置。如上所述它保留 FST 中的输入顺序。 因此它无法像基于 n-gram 的方法那样在输入中间进行匹配。 即如果你有一部名为 “Harry Potter and the Goblet of Fire” 的电影并且你输入 “goblet of fire”它不会将文档作为匹配项返回。 但是你可以使用输入选项来提供多个匹配项。 你可以手动对输入字符串进行分词并将分词传递到输入选项中的 Elasticsearch就像我们在上面的示例中通过提供 “Goblet of Fire” 作为附加输入所做的那样。
Completion suggester 支持 fuzzy queries使我们能够在搜索文档时考虑拼写错误。 你还可以指定前缀文本作为正则表达式查询。 下面示例中的两个查询都返回 “Goblet of Fire” 作为建议 -
GET /movies/_search?filter_path**.harry_suggest
{_source: title.input,suggest: {harry_suggest: {prefix: gobet of f,completion: {field: title,fuzzy: {fuzziness: 2}}}}
}
GET /movies/_search?filter_path**.harry_suggest
{_source: title.input,suggest: {harry_suggest: {regex: g[aieou]b,completion: {field: title}}}
} 添加上下文到搜索
与其他查询不同completion suggesters 不支持在查询中添加过滤器。 即你无法根据文档中其他字段的值过滤掉建议。 假设我们有一个存储电影的索引并且我们正在开发基于标题字段的自动完成功能。 假设我们已将 title 映射为完成类型还有其他字段如 genres、ratings、production companies 等。有一个 title 为 “Goblet of Fire” 的文档其 genre 为 “action”。 现在如果我们尝试根据 genre romance 过滤掉自动完成建议我们预计它不应该返回 “Goblet of Fire”
POST /movies/_doc/1001
{genre: action,title: [{input: Harry Potter and the Goblet of Fire,weight: 5},{input: Goblet of Fire,weight: 10}]
}POST /movies/_doc/1002
{genre: fiction,title: {input: [Harry Potter and the Goblet of Fire,Goblet of Fire],weight: 2}
}GET /movies/_search
{query: {bool: {filter: [{term: {genre: romance}}]}},suggest: {harry_suggest: {prefix: goblet,completion: {field: title}}}
}
上述搜索将返回和之前一样的结果。仿佛那个过滤器根本就不存在。这并不像我们预期的那样工作 - 它返回 “Goblet of Fire” 作为建议即使它属于 “action” 类型。 这种限制背后的主要原因是它的设计。 正如已经讨论过的建议存储在单独的数据结构中 - 内存中 FST而其他字段存储在磁盘上。 这种设计有助于通过内存中 FST 进行更快的搜索。 像上面这样的查询违背了这种设计。
然而Elasticsearch 确实提供了上下文建议在一定程度上规避了这个问题。 要使用上下文建议器我们必须在为索引创建映射时提供上下文
DELETE moviesPUT /movies
{mappings: {properties: {title: {type: completion,contexts: [{name: genre,type: category}]}}}
}
对于特定的 completion 字段我们可以定义多个具有唯一名称的上下文。 支持两种类型的上下文
Category 你正在索引的事物的类别例如 电影/歌曲的类型genreGeo 你正在索引的文档的地理点允许根据经纬度过滤建议。
上述每种上下文类型都支持一些高级参数例如精度 (precision)、地理上下文的邻居 (neighbours)、查询时的增强 (boost)以便具有特定类别的文档获得更高的分数。 请注意对于启用上下文的完成字段在索引文档以及查询文档时上下文参数是必需的。
让我们在上面创建的索引中索引一些文档
POST /movies/_doc/2001
{title: {input: Harry Potter and the Chamber of Secrets,contexts: {genre: mystery}}
}POST /movies/_doc/2002
{title: {input: Harry Potter and the Prisoner of Azkaban,contexts: {genre: crime}}
}
上面我们将 Harry Potter and the Prisoner of Azkaban 索引为 “crime” 类型的电影将 Harry Potter and the Chamber of Secrets 索引为 “mystery” 类型的电影。 让我们尝试获取前缀 “harry” 的建议
GET /movies/_search?filter_path**.harry_suggest
{_source: title.input,suggest: {harry_suggest: {prefix: harry,completion: {field: title,contexts: {genre: crime}}}}
}
上面查询的结果为
{suggest: {harry_suggest: [{text: harry,offset: 0,length: 5,options: [{text: Harry Potter and the Prisoner of Azkaban,_index: movies,_id: 2002,_score: 1,_source: {title: {input: Harry Potter and the Prisoner of Azkaban}},contexts: {genre: [crime]}}]}]}
}
从上面的响应中可以看出即使传递的前缀与上面索引的两个文档都匹配也仅返回 “crime” 类型的 “Harry Potter and the Prisoner of Azkaban”。
这就是我们在 Elasticsearch 中实现自动完成的第三种方法。 那么completion suggester 与迄今为止看到的其他方法相比如何 它绝对是最快的因为要搜索的数据在内存中可用但是如果我们决定使用它实现自动完成我们需要记住一些事情
必须注意索引的大小因为建议存储在内存中。中缀 (infix) 匹配例如 不支持按中间名匹配。不支持对文档中其他字段的建议进行高级过滤。
总结一下我们可以说在选择在 Elasticsearch 中实现自动完成功能的方法时应考虑以下因素
数据是否已建立索引 以什么格式 我们可以重新索引它以使其更适合自动完成功能吗 如果数据已经被索引为文本字段并且我们无法重新索引它我们将需要采用查询时间方法 - 即前缀查询 (prefix queries) 该字段可以通过哪些方式查询 以多种方式存储它有意义吗是否需要支持中缀 (infix) 匹配 文本中的单词顺序是固定的吗 用户是否熟悉该顺序 complete suggesters 不支持中缀匹配并且不适合具有众所周知的顺序的字段。将作为值提供给我们的字段的文本的最大大小是多少 如果保存在内存中会产生问题吗 completion suggesters 将数据保存在内存中基于 n-gram 的方法在基本分词化后创建附加分词以实现更快的匹配。我们需要为这个字段建立一个单独的索引吗 如果这里提到的所有三种方法都不能满足你的要求那么你将需要创建另一个索引。 在该索引中只有 auto-complete 功能所需的字段才会存储为唯一文档而不是与同一索引中的其他数据一起保存。 这将最大限度地减少节点膨胀的可能性并且还可以提供更快的建议。 但是是的它毕竟是一个单独的索引你必须保持主索引和新索引之间的数据同步。 管理另一个索引也有开销。
