标签:开源 简单的 服务 mode 解析 说明 http term 需求
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查询接口的语法设计和实现逻辑及简要说明。其中有不合理之处,欢迎指正交流。
更多免费技术资料及视频
标签:开源 简单的 服务 mode 解析 说明 http term 需求
原文地址:https://blog.51cto.com/jssforever/2503772