框架来源
在使用es(elasticsearch)的过程中发现他的api比较复杂,编写特别长。且需要层层嵌套。为了简化开发,由mybatis-plus开源框架得到思路。于是编写了一套简易语句的ORM框架。大部分功能在内部已使用。查询语句遵循elasticsearch的原生语法。match,term等。适合理解elasticsearch原生的查询语句的人。只进行代码相应的简化。聚合也是基于原生api的封装。根据字段名默认指定聚合名.
看一下简单的案例
@Data
@EsIndex(index = "sys_user1")
public class SysUser {
@EsId
private Long id;
@EsField(type = EsFieldType.STRING)
private String username;
/**
* 昵称
*/
private String nickName;
private String phone;
/**
* 真实姓名
*/
private String realName;
/**
* 是否锁定
*/
private Integer lockState;
@EsField(type = EsFieldType.NESTED)
private SysRole sysRole;
private List<Long> ids;
}
@Service
public class SysUserEsService extends EsServiceImpl<SysUser>{
public void search() {
// 声明语句嵌套关系是must
EsResponse<SysUser> esResponse = esChainQueryWrapper().must()
.terms(SysUser::getUsername, "admin", "hzh", "shi")
// 多个must嵌套
.must(a ->
// 声明内部语句关系的should
a.should()
.term(SysUser::getRealName, "dasdsad")
.term(SysUser::getPhone, "1386859111"))
// 查询
.list();
List<SysUser> list = esResponse.getList();
}
public void agg() {
// 声明语句嵌套关系是must
EsChainQueryWrapper<SysUser> esChainQueryWrapper = esChainQueryWrapper().must()
.terms(SysUser::getUsername, "admin", "hzh", "shi")
// 多个must嵌套
.must(a ->
// 声明内部语句关系的should
a.should()
.term(SysUser::getRealName, "dasdsad")
.term(SysUser::getPhone, "1386859111"));
esChainQueryWrapper.esLamdaAggregationWrapper()
// terms聚合并且指定数量10000
.terms(SysUser::getUsername, a -> a.size(10000))
// 在terms聚合的基础上统计lock数量
.subAggregation(t -> t.count(SysUser::getLockSate));
EsResponse<SysUser> esResponse = esChainQueryWrapper
// 查询
.list();
List<SysUser> list = esResponse.getList();
EsAggregationsResponse<SysUser> esAggregationsReponse = esResponse.getEsAggregationsReponse();
// 以下方法选一种
Terms terms = esAggregationsReponse.getTerms(SysUser::getUsername);
Map<String, Long> termsAsMap = esAggregationsReponse.getTermsAsMap(SysUser::getUsername);
}
}
特殊功能
对es索引的属性settings的变更会进行自动更新。会自动添加新的映射。如果是变更的映射会开启重新reindex(需要开启,(可能有不足))
开启后将通过es的分布式锁,指定索引内数据得更新时间等技术保证reindex后的数据是最新的不会有遗漏数据。保证reindex期间创建更新的数据也会更新到新索引。但是无法保证在reindex时候被删除的脏数据。所以依然推荐在业务低谷期执行。如果有已经被删除的脏数据可以手动删除,或者还有另外的策略待完善。
最后
个人对elasticsearch的使用并不多。如果有不足欢迎指出。
供大家学习和使用参考。喜欢的朋友点个赞
github
gitee