Elastic Search經常使用元數據簡介

在ES中，除了定義的index，type，和管理的document外，還有若干的元數據。這些元數據用於記錄ES中須要使用的核心數據。在ES中，元數據一般使用下劃線’_’開頭。

1 查看數據
GET /index_name/type_name/id
如：
GET /test_index/my_type/1
結果：

{
    "_index": "test_index",
    "_type": "my_type",
    "_id": "1",
    "_version": 1,
    "found": true,
    "_source": {
        "name": "test_doc_01",
        "remark": "first test elastic search",
        "order_no": 1
    }
}

　　

2 _index
表明document存放在哪一個index中，_index就是索引的名字。生產環境中，相似的Document存放在一個index中，非相似的Document存放在不一樣的index中。一個index中包含若干類似的Document。index名稱必須是小寫的，且不能如下劃線'_'，'-'，'+'開頭。

3 _type
表明document屬於index中的哪一個type（類別），就是type的名字。ES6.x版本中，一個index只能定義一個type。結構相似的document保存在一個index中。Type命名要求：字符大小寫無要求，不能下劃線開頭，不能包含逗號。（ES低版本，5.x或更低版本。通常一個索引會劃分若干type，邏輯上對index中的document進行細緻的劃分。在命名上，能夠全大寫或者全小寫，不能下劃線開頭，不能包含逗號。）

4 _id
表明document的惟一標識。使用index、type和id能夠定位惟一的一個document。id能夠在新增document時手工指定，也能夠由es自動建立。
4.1 手動指定id
語法：
PUT /index_name/type_name/id_value
{
    "field_name" : "field_value"
}

使用這種方式，須要考慮是否知足手動指定id的條件。若是數據是從其餘數據源中讀取並新增到ES中的時候，使用手動指定id。如：數據是從Database中讀取並新增到ES中的，那麼使用Database中的PK做爲ES中的id比較合適。建議，不要把不一樣表的數據新增到同一個index中，可能有id衝突。
4.2 自動生成id
語法：
POST /index_name/type_name
{
    "field_name" : "field_value"
}
自動生成的ID特色：長度爲20的字符串；URL安全（通過base64編碼的）；GUID生成策略，支持分佈式高併發（在分佈式系統中，併發生成ID也不會有重複可能，參考https://baike.baidu.com/item/GUID/3352285?fr=aladdin）。適合用於手工錄入的數據。數據沒有一個數據源，且未通過任何的管理和存儲。這種數據，是沒有惟一標識，若是使用手工指定id的方式，容易出現id衝突，致使數據丟失。相對少見。

5 _source元數據
就是查詢的document中的field值。也就是document的json字符串。此元數據能夠定義顯示結果（field）。語法是：
GET /index_name/type_name/id_value?_source=field_name1,field_name2

6 _version元數據
表明的是document的版本。在ES中，爲document定義了版本信息，document數據每次變化，表明一次版本的變動。版本變動能夠避免數據錯誤問題（併發問題，樂觀鎖），同時提供ES的搜索效率。
第一次建立Document時，_version版本號爲1，默認狀況下，後續每次對Document執行修改或刪除操做都會對_version數據自增1。
刪除Document也會_version自增1。
當使用PUT命令再次增長同id的Document，_version會繼續以前的版本繼續自增。