複雜資料型別

除了前面說到的簡單資料型別，Elasticsearch還支援JSON 的null ，陣列，和物件.

空域

欄位取值可以為空，當然，陣列也可以為空。 然而，在 Lucene 中是不能儲存 null 值的，所以我們認為存在 null 值的域為空域。

下面三種域被認為是空的，它們將不會被索引：

"null_value":               null,
"empty_array":              [],
"array_with_null_value":    [ null ]

陣列域

很多時候，我們希望 tag 域 包含多個標籤。我們可以以陣列的形式索引標籤：

{
 
 "tag": [ "search", "nosql" ]}

對於陣列，沒有特殊的對映需求。任何域都可以包含0、1或者多個值，就像全文域分析得到多個詞條。

這暗示 陣列中所有的值必須是相同資料型別的 。你不能將日期和字串混在一起。如果你通過索引陣列來建立新的域，Elasticsearch 會用陣列中第一個值的資料型別作為這個域的 型別 。

注意:
當你從 Elasticsearch 得到一個文件，每個陣列的順序和你當初索引文件時一樣。你得到的 _source 域，包含與你索引的一模一樣的 JSON 文件。

但是，陣列是以多值域 索引的—可以搜尋，但是無序的。 在搜尋的時候，你不能指定 “第一個” 或者 “最後一個”。 更確切的說，把陣列想象成 裝在袋子裡的值 。

多層級物件

內部物件 經常用於嵌入一個實體或物件到其它物件中。例如，與其在 tweet 文件中包含 user_name 和 user_id 域，我們也可以這樣寫：

{
    "tweet":            "Elasticsearch is very flexible",
    "user": {
        "id":           "@johnsmith",
        "gender":       "male",
        "age":          26,
        "name": {
            "full":     "John Smith"
 
,
            "first":    "John",
            "last":     "Smith"
        }
    }
}

內部物件的對映

Elasticsearch 會動態監測新的物件域並對映它們為 物件 ，在 Elasticsearch 6之前properties 屬性下列出內部域：

{
  "gb": {
    "tweet": 
      "properties": {
        "tweet":            { "type": "string" },
        "user": {
          "type":             "object",
          "properties": {
            "id":           { "type": "string" },
            "gender":       { "type": "string" },
            "age":          { "type": "long"   },
            "name":   { 
              "type":         "object",
              "properties": {
                "full":     { "type": "string" },
                "first":    { "type": "string" },
                "last":     { "type": "string" }
              }
            }
          }
        }
      }
    }
  }
}

user 和 name 域的對映結構與 tweet 型別的相同。事實上， type 對映只是一種特殊的 物件 對映，我們稱之為 根物件 。除了它有一些文件元資料的特殊頂級域，例如 _source 和 _all 域，它和其他物件一樣。

注：
elasticsearch6以後沒有object型別了，預設巢狀處理了。elasticsearch6以後對映查詢結果如下：

{
  "test": {
    "mappings": {
      "test": {
        "properties": {
          "tweet": {
            "type": "text",
            "fields": {
              "keyword": {
                "type": "keyword",
                "ignore_above": 256
              }
            }
          },
          "user": {
            "properties": {
              "age": {
                "type": "long"
              },
              "gender": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              },
              "id": {
                "type": "text",
                "fields": {
                  "keyword": {
                    "type": "keyword",
                    "ignore_above": 256
                  }
                }
              },
              "name": {
                "properties": {
                  "first": {
                    "type": "text",
                    "fields": {
                      "keyword": {
                        "type": "keyword",
                        "ignore_above": 256
                      }
                    }
                  },
                  "full": {
                    "type": "text",
                    "fields": {
                      "keyword": {
                        "type": "keyword",
                        "ignore_above": 256
                      }
                    }
                  },
                  "last": {
                    "type": "text",
                    "fields": {
                      "keyword": {
                        "type": "keyword",
                        "ignore_above": 256
                      }
                    }
                  }
                }
              }
            }
          }
        }
      }
    }
  }
}

內部物件的索引

Lucene 不支援內部物件。 Lucene 文件是由一組鍵值對列表組成的。為了能讓 Elasticsearch 有效地索引內部類，它把我們的文件轉化成這樣：

{
    "tweet":            [elasticsearch, flexible, very],
    "user.id":          [@johnsmith],
    "user.gender":      [male],
    "user.age":         [26],
    "user.name.full":   [john, smith],
    "user.name.first":  [john],
    "user.name.last":   [smith]
}

內部域 可以通過名稱引用（例如， first ）。為了區分同名的兩個域，我們可以使用全 路徑 （例如， user.name.first ） 或 type 名加路徑（ tweet.user.name.first ）。

在前面簡單扁平的文件中，沒有 user 和 user.name 域。Lucene 索引只有標量和簡單值，沒有複雜資料結構。

內部物件陣列

假設我們有個 followers 內部物件陣列：

{
    "followers": [
        { "age": 35, "name": "Mary White"},
        { "age": 26, "name": "Alex Jones"},
        { "age": 19, "name": "Lisa Smith"}
    ]
}

這個文件會像我們之前描述的那樣被扁平化處理，結果如下所示：

{
    "followers.age":    [19, 26, 35],
    "followers.name":   [alex, jones, lisa, smith, mary, white]
}

但是這裡有一個問題，{age: 35}和 {name: Mary White}之間的相關性已經丟失了，因為每個多值域只是一包無序的值，而不是有序陣列。這足以讓我們問，“有一個26歲的追隨者？”

但是我們不能得到一個準確的答案：“是否有一個26歲 名字叫 Alex Jones 的追隨者？”

巢狀物件

考慮到上面內部物件陣列的問題，我們看下面的例子：

由於在 Elasticsearch 中單個文件的增刪改都是原子性操作,那麼將相關實體資料都儲存在同一文件中也就理所當然。 比如說,我們可以將訂單及其明細資料儲存在一個文件中。又比如,我們可以將一篇部落格文章的評論以一個 comments 陣列的形式和部落格文章放在一起：

PUT /my_index/blogpost/1
{
  "title": "Nest eggs",
  "body":  "Making your money work...",
  "tags":  [ "cash", "shares" ],
  "comments": [ 
    {
      "name":    "John Smith",
      "comment": "Great article",
      "age":     28,
      "stars":   4,
      "date":    "2014-09-01"
    },
    {
      "name":    "Alice White",
      "comment": "More like this please",
      "age":     31,
      "stars":   5,
      "date":    "2014-10-22"
    }
  ]
}

如果我們依賴欄位自動對映,那麼 comments 欄位會自動對映為 object 型別。

由於所有的資訊都在一個文件中,當我們查詢時就沒有必要去聯合文章和評論文件,查詢效率就很高。

但是當我們使用如下查詢時,上面的文件也會被當做是符合條件的結果：

GET /my_index/blogpost/_search
{
  "query": {
    "bool": {
      "must": [
        { "match": { "name": "Alice" }},
        { "match": { "age":  28      }} 
      ]
    }
  }
}

Alice實際是31歲,不是28!
注：
elasticsearch6之後的版本沒有整個問題，被解決了，6之後的查詢結果沒有命中，結果如下：

{
  "took": 0,
  "timed_out": false,
  "_shards": {
    "total": 5,
    "successful": 5,
    "skipped": 0,
    "failed": 0
  },
  "hits": {
    "total": 0,
    "max_score": null,
    "hits": []
  }
}

正如我們在 物件陣列 中討論的一樣,出現上面這種問題的原因是 JSON 格式的文件被處理成如下的扁平式鍵值對的結構。

{
  "title":            [ eggs, nest ],
  "body":             [ making, money, work, your ],
  "tags":             [ cash, shares ],
  "comments.name":    [ alice, john, smith, white ],
  "comments.comment": [ article, great, like, more, please, this ],
  "comments.age":     [ 28, 31 ],
  "comments.stars":   [ 4, 5 ],
  "comments.date":    [ 2014-09-01, 2014-10-22 ]
}

Alice 和 31 、 John 和 2014-09-01 之間的相關性資訊不再存在。雖然 object 型別 (參見 內部物件) 在儲存 單一物件 時非常有用,但對於物件陣列的搜尋而言,毫無用處。

巢狀物件 就是來解決這個問題的。將 comments 欄位型別設定為 nested 而不是 object 後,每一個巢狀物件都會被索引為一個 隱藏的獨立文件 ,舉例如下:

{ #第一個 巢狀文件
  "comments.name":    [ john, smith ],
  "comments.comment": [ article, great ],
  "comments.age":     [ 28 ],
  "comments.stars":   [ 4 ],
  "comments.date":    [ 2014-09-01 ]
}
{ #第二個 巢狀文件
  "comments.name":    [ alice, white ],
  "comments.comment": [ like, more, please, this ],
  "comments.age":     [ 31 ],
  "comments.stars":   [ 5 ],
  "comments.date":    [ 2014-10-22 ]
}
{ #根文件 或者也可稱為父文件
  "title":            [ eggs, nest ],
  "body":             [ making, money, work, your ],
  "tags":             [ cash, shares ]
}

在獨立索引每一個巢狀物件後,物件中每個欄位的相關性得以保留。我們查詢時,也僅僅返回那些真正符合條件的文件。

不僅如此,由於巢狀文件直接儲存在文件內部,查詢時巢狀文件和根文件聯合成本很低,速度和單獨儲存幾乎一樣。

巢狀文件是隱藏儲存的,我們不能直接獲取。如果要增刪改一個巢狀物件,我們必須把整個文件重新索引才可以。值得注意的是,查詢的時候返回的是整個文件,而不是巢狀文件本身。

巢狀物件對映

設定一個欄位為 nested 很簡單 —  你只需要將欄位型別 object 替換為 nested 即可：

PUT /my_index
{
  "mappings": {
    "blogpost": {
      "properties": {
        "comments": {
          "type": "nested", 
          "properties": {
            "name":    { "type": "string"  },
            "comment": { "type": "string"  },
            "age":     { "type": "short"   },
            "stars":   { "type": "short"   },
            "date":    { "type": "date"    }
          }
        }
      }
    }
  }
}