认识达内从这里开始

搜索栏相信大家在访问一些网页的时候都见过吧。主要就是为了方便用户快速搜索一些需要的内容而设置的，所以我们今天就一起来了解一下，当在进行网页开发的时候，搜索栏的功能是依托于什么技术来实现的。下面就开始今天的主要内容吧。

ElasticSearch(后面简称ES)是一个开源的文本检索服务框架，为很多公司提供了检索服务。ES目前功能比较多，使用方便，但肯定不能解决所有问题，只用它来做检索服务可能会更合适。比如我们公司的人才搜索服务，简单来说就是给定查询搜索出相关的人才。这里ES会有些点没有很好的覆盖或不够有效。

中文分词默认不提供

这个一般都会配置相关中文分词插件，我们也是采用使用JNI封装好自己的分词器，以插件形式提供给每个ES节点

不包含查询意图分析

或者说具体一个业务，需要自己在开发查询分析

摘要不包含，高亮特性比较鸡肋

没有文档摘要服务，高亮支持比较粗暴，直接在索引上支持，为了高亮特性，你需要开启正向索引，索引大小会剧增。而且对于Nestedobject，高亮支持比较所限。

缺少业务相关性的计算机制

一个搜索过去，返回就是一堆文档，以及一些文本相关性得分，可以调整的空间有限。

一般一个具体业务，query更文档的相关性会有些更多的考量，希望更精细的控制相关性。

人才搜索架构

针对以上提到的问题，我们的人才搜索在ES上补充些组件来完成业务需求，架构图如下：

搜索前端

这个服务收取来自其他系统的查询请求，带有一个LRUCache，可以缓存比如10分钟以内的相同查询结果。其他他就是一个中控作用，发查询给Query分析服务，得到分析结果后发给Searcher，从Searcher得到结果后，又发分析结果以及指定页文档ID给Abstracter,Abstracter给出摘要高亮结果，最后返回

QueryParser

查询分析是最重要的一个服务，这里会看这个查询的意图，某个query是否公司名查询，职位查询等等。同时，查询中哪些是核心词必须命中，哪些非强制命中，哪些词是需要高亮，那些词可以做哪种扩展，哪些可以不用高亮，哪些词对应文档中哪些字段高亮等，最后如果一次检索结果数不够，二次检索策略的一些提示都可以在这一步完成

Searcher

这个服务接收来自搜索前端的query分析结果，调用查组装(QueryComposer)的组件，根据查询意图等组装出需要发给ES集群的Query。

ES集群给出结果后，这边会对前几页结果调用Ranker组件来根据业务需求排序。

这个排序可以是由LearningToRank算法学出来的模型来完成，会综合各种业务场景，特征来排序。

细心的同学可能会问，在这里排序怎么保证全局的排序是对的，一般而言，我们在Searcher发出的请求是直接请求前200条结果的，翻页之类的由搜索前端缓存来解决。另外，ES的文本相关性机制来保证这头部的200条是大致相关的，我们这里的Ranker相当于最顶层的一个排序器。

Abstracter

摘要服务根据query解析结果，对命中结果计算最合适的高亮结果，提供给业务一个摘要信息

【免责声明】本文系本网编辑部分转载，转载目的在于传递更多信息，并不代表本网赞同其观点和对其真实性负责。如涉及作品内容、版权和其它问题，请在30日内与管理员联系，我们会予以更改或删除相关文章，以保证您的权益！