elasticsearch 一对多嵌套文档_elasticsearch 多层嵌套

基于lucene的搜索引擎elasticsearch就是为大数据搜索而生，其中内置的倒排索引极大的提高了效率。当然，生产环境中不仅仅是单一的文档，还有很多的关联文档。就比如一对多业务数据，我们可以用普通一对多子文档、嵌套文档都能够处理。但是前面我们介绍了普通一对多文档有子对象边界值问题，那么我们嵌套子文档就能够解决这个问题。

什么是嵌套文档
嵌套文档就是在文档中再申明一个 nested 类型的属性。这个属性用来保存我们的子对象，就好像嵌套在主文档里面的一样。嵌套文档不存在普通一对多的边界值问题，其极大的满足了特殊业务场景。

优势与劣势
优点：
1、父子文档在一起，文档管理容易
2、解决了普通一对多文档的边界值问题，能够适应更多的需求
缺点：
1、嵌套文档父子都保存在同一个文档，占用内存过大
2、如果任意修改一个字段都必须修改全部文档，维护复杂

小试牛刀
为方便测试与查看执行脚本，我们采用kibana进行测试
比如：
产品product，包含 名称-name、渠道-channel 两个属性
渠道channel,包含 渠道名称-channelName、渠道价值-channelPrice 两个属性

1、首先创建产品用例索引

PUT product

PUT product/_mapping
{
  "properties":{
    "name":{
      "type": "keyword"
    },
    "channel":{
      "type":"nested",
      "properties":{
        "channelName":{
          "type": "keyword"
        },
        "channelPrice":{
          "type": "integer"
        }
      }
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21

2、查看当前索引

GET product
1

2、写入两个测试文档

PUT product/_doc/1
{
  "name":"产品1",
  "channel":[
    {
      "channelName":"产品1渠道1",
      "channelPrice": 200
    },
    {
      "channelName":"产品1渠道2",
      "channelPrice": 300
    }
 ]
}

PUT product/_doc/2
{
  "name":"产品2",
  "channel":[
    {
      "channelName":"产品2渠道1",
      "channelPrice": 1100
    },
    {
      "channelName":"产品2渠道2",
      "channelPrice": 400
    }
 ]
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29

3、查看测试数据

GET product/_search
{  
}
1
2
3

4、嵌套查询
用例1：
产品2 + 产品2渠道1 + 1100

GET product/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "name": {
              "value": "产品2"
            }
          }
        },
        {
          "nested": {
            "path": "channel",
            "query": {
              "bool": {
                "must": [
                  {
                    "term": {
                      "channel.channelPrice": {
                        "value": 1100
                      }
                    }
                  },
                  {
                    "term": {
                      "channel.channelName": {
                        "value": "产品2渠道1"
                      }
                    }
                  }
              
                ]
              }
            }
          }
        }
        
      ]
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43

预期结果：

能够命中

实际结果：

能够命中

用例2：
产品2 + 产品2渠道1 + 400

GET product/_search
{
  "query": {
    "bool": {
      "must": [
        {
          "term": {
            "name": {
              "value": "产品2"
            }
          }
        },
        {
          "nested": {
            "path": "channel",
            "query": {
              "bool": {
                "must": [
                  {
                    "term": {
                      "channel.channelPrice": {
                        "value": 400
                      }
                    }
                  },
                  {
                    "term": {
                      "channel.channelName": {
                        "value": "产品2渠道1"
                      }
                    }
                  }
                ]
              }
            }
          }
        }
      ]
    }
  }
}
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

预期结果：

未命中

实际结果：

未命中

结论：

嵌套文档不存在边界值问题，在一对多的实际业务场景中，能够有效完成特殊查询响应。但是，我们更新嵌套文档的某一属性，必须更新整个文档，极大的影响了操作复杂度与实际性能。我们可用用 父子文档 进行规避。