opensearch Search使用实例分析

85次阅读
没有评论

共计 2384 个字符,预计需要花费 6 分钟才能阅读完成。

本文丸趣 TV 小编为大家详细介绍“opensearch Search 使用实例分析”,内容详细,步骤清晰,细节处理妥当,希望这篇“opensearch Search 使用实例分析”文章能帮助大家解决疑惑,下面跟着丸趣 TV 小编的思路慢慢深入,一起来学习新知识吧。

[使用背景]

  相信很多人都遇到过要给网站或者 app 做一个搜索功能的需求,很久之前自己折腾过 lucene,搞了很久,要自己搞中文分词(比如用中科院的那个)重写 tokenizer,自己建索引,做实时更新流程,数据量大了还要考虑怎样给数据分环等等各种问题。从 2014 年初开始接触 opensearch,当时来往要做扎堆搜索(包括搜扎堆,搜帖子,搜某个堆内的帖子,搜堆内成员等)从上手到熟练使用 opensearch 只用了大概不到 1 周的时间,总体来说非常满意。感觉这个东西非常符合互联网创业的节奏,简单方便,很快的就能实现自己的搜索接口。

[使用过程]

  以建立一个来往的扎堆搜索为例(如果不知道扎堆是啥,就理解成类似于百度贴吧的东西),比如搜赵薇,我们能找到赵薇相关的扎堆。我来简单讲述一下怎样迅速的用 opensearch 搭建一个搜索接口。

1. 注册 opensearch 的账号,按操作来就好了。

2. 创建一个应用,定义索引结构。例如:

  这里面可搜索,可以理解成需要建索引的字段,比如扎堆的名字,扎堆的 pinyin 名字,扎堆的标签等。可聚合我这目前没有使用,先不管这个。可过滤,比如某个字段 (checkin_type) 表示有的扎堆是私密的,有的不是,那么需要把 checkin_type 勾选成可过滤,这样在检索的时候可以写语句来选取保留哪些符合条件的搜索结果。可展示表示,搜索接口出来我们要给 client 显示哪些字段。

3. 数据导入,opensearch 提供了 3 种数据导入的方式可以根据应用需要自己选择。比如从 mysql 导入,都是图形化的界面,需要做的只是将 mysql 中的字段和刚才建立的索引结构的字段对应起来。也可以通过 hdfs,和 sdk 还有 http 的 api 把数据 push 过来,sdk 和 http 的 api 方式非常灵活,具体做法可以参考帮助文档讲的很清楚。[注:mysql\hdfs 只有内网支持]

4. 建立索引,在界面里点击数据导入这个 tab,会有索引重建这块,点击现在重建,opensearch 会从刚才我们配置的数据库里,按照配置的字段对应方式,从数据库里读出数据并建立索引。等待这个过程结束,就可以访问搜索接口了。

5. 访问搜索接口,在应用首页的右上角点搜索测试。

如图中有 http 的接口,访问后返回的是 json 格式的搜索结果数据。这样最简单的一个搜索雏形就这样搭建出来了。

[使用技巧]

下边说一些可能会遇到的需求和问题:

1.  比如遇到排序需求,例如需要 A 字段命中比 B 字段的命中要更重要,即 A 字段匹配的好的要排在前面(比如 title 和 content)。这样可以自定义排序公式,可以参考文档这里给了很多排序函数,比如可以用 bm25 算法算静态分,text_relevance 算和某个字段的匹配程度,fieldterm_proximity 计算匹配的密度,也有按时间字段衰减的函数。

2.  比如遇到一些召回方面的需求,例如搜 zhoujielun 希望可以搜出周杰伦,搜明星可以出所有明星相关的文档(并不一定包含明星两个字),可能通常比较大的搜索引擎通过 query refine 和 query correct 这种类似的模块来分析 query 来扩大召回,这里可以稍微投机一下,我们把确定的希望召回的 term 可以做成一个新的字段放到索引结构里,并给这些字段一个排序的权重来做到召回并可以合适的排序。

3.  比如遇到搜索附近的事物的需求,排序函数里提供了一个 distance 函数,是算球面距离的,这个方法是 o(n)的,如果数据多了,可能效率会有影响。我们可以在索引结构里做一个字段,用 geohash 算法 (此算法参考 http://en.wikipedia.org/wiki/Geohash) 将 query 里的二维坐标变成一些前缀相同的字符串(比如我们可以固定留 5,6,7,8 位的),把这些 geohash 后的字符串放到这个新的索引字段里。检索的时候也同样把输入的二维坐标算出 5,6,7,8 位的 geohash 串,在这些串能索引到的数据里用 distance 函数进行更精准的距离计算并排序,可以很高效的完成附近的事物的搜索。

4.  另外数据量这块,目前数据量最大的索引约有 5000w 个 doc,这个状况下在 qps500 的时候依然可以做到 10ms 以内返回搜索结果(当然搜索结果的每个 doc 的可展示字段不要太大,这样响应时间会因为网络传输数据变的慢一些)。

[需求]

1. 还有发现一些查询的 badcase,在 query 分析和结果的求交求并这块还是有些 badcase 的,例如假如我们搜 周杰伦中学照片,按照重要程度感觉上是周杰伦 中学 = 照片,即使没有全命中的文章,那么也应该召回周杰伦照片或者   周杰伦的文档。相信这块会越做越好的。

OpenSearch 解答:目前正在开发一个新功能,会对用户 query 做多个维度的改写,比如低权重 term 降权,支持用户自定义词典(同义词、纠错、停用词、专业词等),会进一步提升长尾词的搜索效果,降低无结果率。

2. 如果能提供相关搜索功能就更好了:). 比如根据这个搜索应用经常搜的一些 query 的 log,给出搜这个 query 的用户还可能搜什么词儿。

OpenSearch 解答:相关搜索、下拉提示等功能都已经在规划中,包括后续的点击反馈、个性化搜索我们都已经开始调研工作了,敬请期待。

读到这里,这篇“opensearch Search 使用实例分析”文章已经介绍完毕,想要掌握这篇文章的知识点还需要大家自己动手实践使用过才能领会,如果想了解更多相关内容的文章,欢迎关注丸趣 TV 行业资讯频道。

正文完
 
丸趣
版权声明:本站原创文章,由 丸趣 2023-08-04发表,共计2384字。
转载说明:除特殊说明外本站除技术相关以外文章皆由网络搜集发布,转载请注明出处。
评论(没有评论)