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

Posted 2020-12-10

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

一、为什么需要查询代理

屏蔽复杂的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包依赖

· 其它可能出现的限制

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

松耦合及管控

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

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

二、查询代理层实现

业界做法

业界有将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

三、总结

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

更多免费技术资料及视频