Elasticsearch (ES)是一款基于Lucene的开源分布式搜索引擎。由于其稳定,可靠,快速、安装使用方便等优良特性,目前在业界已广泛使用。用途主要分两个方向:分布式实时文件存储,以及,分布式实时分析搜索引擎。
一、为什么需要查询代理
屏蔽复杂的DSL
某二手交易平台使用,主要用来支持商品,用户等(以下统称文档)的搜索和分析。
ES为查询功能提供了基于Json的完整查询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无法完整实现目标需求,而且文档属性非常多的情况下,容易产生语句过于复杂的问题。
方案
种种因果,我们最终的实现方案如下:
请求语法
·,,,,,,,,语句分域为查询和参数域,查询域为筛选召回条件,参数域为排序参数;
·,,,,,,,,域为属性字段的组合;
·,,,,,,,,域使用URL参数语法表述;
还以搜索昵称为化仁的用户为例,请求如下:
查询:从=1,大?10,昵称=化仁,参数:null 请求会自动转换成前面提到DSL的例子。可以看的到,相比之下还是非常简单的。
实现逻辑
补充说明:
·,,,,,,,,根据解析方式,字段大致分为:内置字段,(起始位置,获取数量,排序策略等),和,配置字段,(字符串,数值,日期,经纬度等,会解析成对应ES支持的索引字段类型)
·,,,,,,,,配置字段根据使用场景分为:匹配筛选型,排序参数型,字段排序型,排序打分型,二次打分型等
·,,,,,,,,各种类型的配置字段配有配置解析器和请求处理器
·,,,,,,,,处理过程中会做诸如字段默认值,非法字段过滤等处理
·,,,,,,,,处理过程生成查询的梗概信息作为外部缓存的关键值,减轻ES集群压力
·,,,,,,,,请求经过校验,解析,处理后拼装成ES的DSL,请求发送到系统分配ES集群
配置样例:
yml条目。用户:指数:用户类型:用户query_fields: - - - - - -{脸:id,类型:数字、类:长}-{脸:昵称,类型:StringMultiMatch fieldName:“昵称,nickname.pinyin", _tie_breaker: 1} order_strategys:默认值:boostMode:用得分:-类型:NumberTermsFilter fieldName: label_idclass:长值:“1141730738345”;重量:2
三,总结
本文从ES查询接口的必要性出发,主要讲述了某二手交易平台ES查询接口的语法设计和实现逻辑及简要说明。其中有不合理之处,欢迎指正交流。
更多免费技术资料及视频
