今年写了一个数据中心的项目，其中有相当一部分的数据查询，用的是ES来做的，涉及到dsl的查询语句，从最开始的简单查询，到后面的复杂的查询，逐步掌握了ES的常用写法，现在总结一下。
文章内的称呼，没有按照ES的官方称呼，例如sql那边的表叫type，sql那边的行叫documents，sql那边的列或者字段叫fields。为了方便起见，统一按照sql的叫法。
书接上回
{
"size": 0,
"query": {
"bool": {
"must": [
{
"bool": {
"must": [
{
"terms": {
"order_status": [
2,
5,
9
]
}
},
{
"nested": {
"path": "order_detail_list",
"query": {
"terms": {
"order_detail_list.goods_id": [123,313,3123,324,5345]
}
}
}
},
{
"term": {
"pay_type": 5
}
},
{
"range": {
"order_time": {
"gte": "2022-08-01 00:00:00",
"lte": "2022-08-30 23:59:59"
}
}
}
]
}
},
{
"bool": {
"must_not": [
{
"match_phrase": {
"user_remark": {
"query": "换货单"
}
}
}
]
}
}
]
}
},
"aggs": {
"total_order_count": {
"cardinality": {
"field": "union_pay_order_id",
"precision_threshold": 50000000
}
},
"order_detail": {
"nested": {
"path": "order_detail_list"
},
"aggs": {
"group_by_goods": {
"filter": {
"terms": {
"order_detail_list.goods_id": [123,313,3123,324,5345]
}
},
"aggs": {
"total_money": {
"sum": {
"script": {
"lang": "painless",
"inline": "doc['order_detail_list.count'].value * doc['order_detail_list.price'].value"
}
}
},
"total_count": {
"sum": {
"field": "order_detail_list.count"
}
}
}
}
}
}
}
}
在这个代码中，对数据的内嵌的内容，做了条件查询，并对内层进行数据聚合。
ES数据的存储结构，不是sql的那种整齐的表格结构，ES由于自身特性，可以做数据嵌套的存储。
本次的查询对象，结构大概如下：
订单表
-订单时间
-订单状态
-订单金额
--订单商品列表
--订单商品1
---商品1的ID
---商品1的数量
---商品1的单价
--订单商品2
---商品2的ID
---商品2的数量
---商品2的单价
--订单商品3
---商品3的ID
---商品3的数量
---商品3的单价
订单表外层是订单的各种信息，例如订单时间，订单状态，收货地址，收货人信息等信息。
由于一个订单一般都不止一个商品，那就会有一个商品列表，对应的购买时商品的单价，商品的数量等信息。
上篇提到的加条件的方法，只能加在外层的订单信息的某个字段上，不能加在内层的商品信息上，使用“nested”进入订单明细，然后指定明细内的字段，例如代码中是“order_detail_list.goods_id”指定的商品ID，然后条件才生效。
如果以为这样查出来的结果，就是我们想要的了，那还有点为时尚早，因为这样只是将ES里的原始数据，进行了指定条件的过滤而已。此时在后面直接写聚合，依然还会出错。
1是进入内嵌的商品明细里面，2是按照商品ID进行过滤。
前面在“query”里面加的过滤条件，只能过滤出符合这些条件的原始数据。
举个例子，商品ID为‘123’的商品，在一段时间的销量，就需要先在取出这些商品的数量以及单价，然后进行求和。
"query"阶段的过滤，只是取出来了包含了123商品的订单，这些订单也会包含456,789的商品。
举例订单：
订单1：{
商品123，数量2，单价2.5
商品456，数量7，单价1.1
商品789，数量6，单价15.6
},
订单2：{
商品123，数量5，单价2.6
商品145，数量7，单价3.1
商品348，数量5，单价9.4
}
如果只是在"query"加了条件，那么在聚合时，就会得到结果：
22.5+71.1+615.6+22.5+73.1+59.4
但是我们需要的是：
22.5+52.6
很显然这样的结果是不符合要求的。
所以在聚合的时候，也要加上商品的过滤条件，图中红框2部分。
顺便提一嘴红框3，这个功能是统计有多少去重后的union_pay_order_id。类似于上篇的统计去重之后的用户个数。
写到这里，有人可以会说，只在内嵌的商品ID加上过滤条件就可以了，就是只加在aggs这个部分，前面的“query”部分应该可以不加这个条件。没错，只在aggs部分加条件，就可以查出商品对应的金额，但是查不出来商品对应的订单的个数。两个查询语句对应的不同结果如下：
可以看到，query部分加了条件，订单个数统计是没有问题的，没加条件的，订单个数统计的就是全部。其他的求和件数和金额的数据是没有问题的。
红框内的表示的是ES表的内嵌的字段，"order_detail_list"是一级的字段，“count"是内嵌的二级字段，两个字段用”."隔开。
需要注意到，绿色的框内是一个 乘法，就是说这个和sql一样可以在聚合之前，对两个字段进行相乘。
还有就是在"nested"之后，有两次aggs，第一次是按照goods_id进行聚合，第二次是对商品的金额进行聚合，这里可以类比于sql：
select sum(count*price), sum(count)
from xxx
where goods_id in (123,313,3123,324,5345)
注意 【不是】 先按照goods_id聚合，后按照数量聚合，类似于这种：
select goods_id, sum(count*price), sum(count)
from xxx
where goods_id in (123,313,3123,324,5345)
group by goods_id
在这里插入代码片
红框中标出的就是需要的结果的值：外层是订单的个数；内层是内嵌字段的聚合，对商品的金额和件数进行求和，这部分不用详细分析了。
如何实现类似于这个sql的功能呢：
select goods_id, sum(count*price), sum(count)
from xxx
where goods_id in (123,313,3123,324,5345)
group by goods_id
再次加上一个aggs，对内嵌的goods_id聚合就可以了
我的写法：
{
"size": 0,
"query": {
"bool": {
"must": [
{
"bool": {
"must": [
{
"terms": {
"order_status": [
2,
5,
9
]
}
},
{
"nested": {
"path": "order_detail_list",
"query": {
"terms": {
"order_detail_list.goods_id": [123,313,3123,324,5345]
}
}
}
},
{
"term": {
"pay_type": 5
}
},
{
"range": {
"order_time": {
"gte": "2022-01-01 00:00:00",
"lte": "2022-08-30 23:59:59"
}
}
}
]
}
},
{
"bool": {
"must_not": [
{
"match_phrase": {
"user_remark": {
"query": "换货单"
}
}
}
]
}
}
]
}
},
"aggs": {
"total_order_count": {
"cardinality": {
"field": "union_pay_order_id",
"precision_threshold": 50000000
}
},
"order_detail": {
"nested": {
"path": "order_detail_list"
},
"aggs": {
"group_by_goods": {
"filter": {
"terms": {
"order_detail_list.goods_id": [123,313,3123,324,5345]
}
},"aggregations": {
"per_goods": {
"terms": {
"field": "order_detail_list.goods_id"
},
"aggs": {
"total_money": {
"sum": {
"script": {
"lang": "painless",
"inline": "doc['order_detail_list.count'].value * doc['order_detail_list.price'].value"
}
}
},
"total_count": {
"sum": {
"field": "order_detail_list.count"
}
}
}
}
}
}
}
}
}
}
这一部分就先写到这里，这只是我对于ES的自己的总结，难免会有不完整以及错误的地方，欢迎指正。