• 1, 业务代码实现结果和kibana验证不一致。
  比如：我的python或者java程序检索结果怎么和kibana里面不一致？
• 2, 我的某个关键词明明匹配，但怎么检索不到？
  比如：星球群讨论的“三星”ik_max_word + match_phrase匹配问题。
• 3, 熟悉sql，但转dsl就不会写了。
  比如：做聚合搜索的话，select * from user where usrid >5  group by userid having count(userid) >3  这个功能能在一个dsl实现吗 ？
• 4, 查询慢，但不知道什么原因导致的。
  比如：elasticsearch有8亿数据查询慢是怎么回事，有什么办法优化。

1、啥是Elasticsearch DSL？

2、DSL的全局认知

2.1 维度1：集群的管理。

2.2 维度2：索引的生命周期管理。

2.2.1、生：创建索引。

• 1、血淋淋的教训：业务上精炼再精炼，一个索引搞定的绝不多表关联。
• 2、提前设计好字段及扩展字段，即便ES支持动态添加字段。
• 3、不使用动态映射，所有字段自己定义，节省存储空间。
  举例：

2.2.2、老：滚动索引、关闭索引或者冻结索引。

2.2.3、病：索引出了问题。

2.2.4、死：删除索引。

2.3 维度3：数据的增删改查。

2.3.1 增

2.3.2 删

2.3.3 改

2.3.4 查

2.4 维度4：数据统计分析

2.5  更多其他维度

3、实践干货

3.1,业务代码实现结果和kibana验证不一致。

3.2,我的某个关键词明明匹配，但怎么检索不到？

3.3,熟悉sql，但转dsl就不会写了。

3.4,查询慢，但不知道什么原因导致的。

• 思路1：索引层面。
  8亿条分散到多个索引、多个副本当中，还是一个索引？
• 思路2：Mapping映射设计层面。
  举例，设计高效检索Number类型建议改成keyword。
  详细参考携程架构师的文章：number?keyword?傻傻分不清楚
• 思路3：检索DSL优化层面
  注意：能使用filter过滤检索的就不要使用query，原理参考我之前梳理的文章：
  吃透 | Elasticsearch filter和query的不同 
• 思路4：返回字段层面
  有没有检索的使用_source:""  限定返回的字段，
  如果没有，会全字段返回，数据量大的话，也会慢。
• 思路5：DSL 调试
  调试方法：DSL执行语句中加上profile:true .
  或者借助：xpack可视化插件排查。
  这样，会打印出对应查询的细节花费时间，让你明明白白知道那里慢了。
• 思路6：日志查询
  查询的时候，查询ES日志，看看有没有大量的gc。
  看看有没有错误日志，错误日志的处理就是优化的方向。
• 思路7：借助cerebro或者xpack mointer监视集群状态
  看一看，集群堆内存、cpu、负载的使用情况。
• 思路8：外部思维
  想一想，查询的时候，有没有并行的写入操作？
  那么查询的时候慢，是不是写入压力大队集群造成的影响。
• 思路9：排除网络慢的原因
  内网查询还是外网映射查询，返回时间也不一样。
• 思路10：其他问题
  结合业务场景进行分析，自己的业务代码逻辑的问题。
  一定要转成DSL进行最小化定位。

4、小结

• 实际业务中的问题远比上面复杂。但开发的过程中，很多时候，走的太久忘记了出发的目的是什么。
• 本文仅起到抛砖引玉作用，更多复杂DSL、脚本、自定义评分等DSL没有涉及，不过原理一致。
• 所以，遇到问题，切莫乱求医。亮出你的DSL，追根溯源、条分缕析逐步细化，问题会迎刃而解。
  一起加油，共勉！