读《深入理解Elasticsearch》点滴-对象类型、嵌套文档、父子关系

一、对象类型

1、mapping定义文件

"title":{
            "type":"text"
        },
"edition":{
            "type":"object",
             "properties":{
                             "isbn":{
                                 "type":"text"
                              }
                           }
          }

2、索引数据

"title":"title_1",
"edition":[
    {
         "isbn":"",
         "circulation":50000
    },
    {
         "isbn":"",
         "circulation":2000
     }
]

3、等效于

"title":"title_1",
"edition"
    {
         "isbn":["",""],
         "circulation":[,]
    }

4、总结一下：

object类型只有在很简单的情景中好用，如“一对一“的父子环境当中；或者不存在跨字段找找等情况是，仅需要在单个字段中搜索而不需要关联多个字段时，或者不需要在对象中搜索。

二、嵌套文档

1、mapping定义

"title":{
            "type":"text"
        },
"edition":{
            "type":"nested",
             "properties":{
                             "isbn":{
                                 "type":"text"
                              }                            }
          }

2、总结

• 普通查询，嵌套文档被自动过滤掉，不会被搜索到或展示出来。这在Lucene中被称为块链接（block join）。出于性能方面的考虑，嵌套文档与主文档保存在一个索引块中
• 主文档与嵌套文档在索引期间同时存储的，又称为“索引期连接（index-time join）。
• 当主文档和嵌套文档都很小，且主文档易于获取时，这种强关联关系并不会造成什么问题。如果这些文档很大，关联双方之一变化频繁，那么重建另外一部分文档变得不太现实里。
• 另外就是如果一个嵌套文档属于多个主文档时，问题会变得非常棘手。

三、parent-child 关系

1、最大的优势，父子关系双方的文档是相互独立的，又称为”查询期连接（query-time join）。

2、代价就是更复杂的查询及更慢的查询性能

3、第二个优势：父子关系适用于大型应用及多节点场景

4、子文档检索并不强制在父文档上下文中进行

5、一个异常的例子：

父数据有1000条，通过hash存储到不同的分片上；

子数据有1000条，所有子数据的对应同一条父数据；

1000条子数据都将存储到同一个分片上。

6、如果某些分文档有多个子文档，会导致文档在分片之间的不均匀分布