五分钟学会Elasticsearch查询代理设计

Elasticsearch（ES）是一款基于Lucene的开源分布式搜索引擎。因为其稳定、可靠、快速、安装使用方便等优良特性，目前在业界已普遍使用。ES用途主要分两个方向：分布式实时文件存储 以及 分布式实时分析搜索引擎。

1、为何须要查询代理

屏蔽复杂的DSL

某二手交易平台使用ES，主要用来支持商品、用户等(如下统称文档)的搜索和分析。

ES为查询功能提供了基于Json的完整Query DSL，功能很是强大，但同时也略显复杂，学习成本不低。

以搜索昵称为化仁的用户为例，DSL大体以下：

json {"from" : 0, "size" : 20, "query" : {"bool" : { "must" : { "multi_match" : {"query" : "化仁", "fields": [ "nickname", "nickname.pinyin" ], "type" :"best_fields", "operator" : "OR","minimum_should_match" : "1", "tie_breaker" : 1.0} }, "filter" : { "term" : { "del" : 0 } } } } }

若是让每一个业务方根据须要编写DSL实现相应功能，工做量及维护复杂程度可想而知！

避免依赖限制扩散

· ES要求客户端和服务端JDK版本尽可能保持一致

· ES2.x要求JDK7以上

· ES5.x要求JDK8以上

· 大量Jar包依赖

· 其它可能出现的限制

使用查询代理以后，各业务方无需引入上述依赖和限制

松耦合及管控

屏蔽底层引擎变更对线上业务的影响，例如底层引擎偶尔须要升级或重启，此时，只需查询代理层实现主从切换等机制，引擎的升级可作到对线上业务彻底透明。

此外，查询代理还能够屏蔽业务方错误的危险操做，防止集群直接暴露给各业务方，从而下降不肯定因素对系统的影响。

2、查询代理层实现

业界作法

业界有将SQL做为代理层语言，实现一套SQL转DSL的解析器，这种方式针对将ES做为DB使用的状况很是合适。可是，前面提到过，某二手交易平台的使用场景是文档的搜索，其中涉及到文档的复杂排序，SQL没法完整实现目标需求，并且文档属性很是多的状况下，容易产生语句过于复杂的问题。

方案

种种因果，咱们最终的实现方案以下：

请求语法

· 语句分为query域和param域，query域为筛选召回条件，param域为排序参数；

· 域为属性字段的组合；

· 域使用URL参数语法表述；

还以搜索昵称为化仁的用户为例，请求以下：

query:from=1&size=10&nickname=化仁 param: null 请求会自动转换成前面提到的DSL例子。能够看到，相比之下仍是很是简单的。

实现逻辑

补充说明：

· 根据解析方式，字段大体分为：内置字段 (起始位置、获取数量、排序策略等) 和 配置字段 (字符串、数值、日期、经纬度等，会解析成对应ES支持的索引字段类型)

· 配置字段根据使用场景分为：匹配筛选型、排序参数型、字段排序型、排序打分型、二次打分型等

· 各类类型的配置字段配有配置解析器和请求处理器

· 处理过程当中会作诸如字段默认值、非法字段过滤等处理

· 处理过程生成query的梗概信息做为外部缓存的key值，减轻ES集群压力

· 请求通过校验、解析、处理后拼装成ES的DSL，请求发送到系统分配ES集群

配置样例：

yml entry.user:index: user type: user query_fields: - { face: id, type: Number, class: Long }- { face: nickname, type: StringMultiMatch, fieldName:"nickname,nickname.pinyin", _tie_breaker: 1 } order_strategys:default: boostMode: multiply scores: - type: NumberTermsFilter fieldName: label_idclass: Long values: "1141730738345" weight: 2

3、总结

本文从ES查询接口的必要性出发，主要讲述了某二手交易平台​ES查询接口的语法设计和实现逻辑及简要说明。其中有不合理之处，欢迎指正交流。

更多免费技术资料及视频