1、_index元數據
2、_type元數據
3、_id元數據
{
"_index": "test_index",
"_type": "test_type",
"_id": "1",
"_version": 1,
"found": true,
"_source": {
"test_content": "test test"
}
}
1、_index元數據
（1）代表一個document存放在哪個index中
（2）類似的數據放在一個索引，非類似的數據放不同索引：product index（包含了所有的商品），sales index（包含了所有的商品銷售數據），inventory index（包含了所有庫存相關的數據）。如果你把比如product，sales，human resource（employee），全都放在一個大的index裏面，比如說company index，不合適的。
（3）index中包含了很多類似的document：類似是什麼意思，其實指的就是說，這些document的fields很大一部分是相同的，你說你放了3個document，每個document的fields都完全不一樣，這就不是類似了，就不太適合放到一個index裏面去了。
（4）索引名稱必須是小寫的，不能用下劃線開頭，不能包含逗號：product，website，blog
2、_type元數據
（1）代表document屬於index中的哪個類別（type）
（2）一個索引通常會劃分爲多個type，邏輯上對index中有些許不同的幾類數據進行分類：因爲一批相同的數據，可能有很多相同的fields，但是還是可能會有一些輕微的不同，可能會有少數fields是不一樣的，舉個例子，就比如說，商品，可能劃分爲電子商品，生鮮商品，日化商品，等等。
（3）type名稱可以是大寫或者小寫，但是同時不能用下劃線開頭，不能包含逗號
3、_id元數據
（1）代表document的唯一標識，與index和type一起，可以唯一標識和定位一個document
（2）我們可以手動指定document的id（put /index/type/id），也可以不指定，由es自動爲我們創建一個id
1、手動指定document id
（1）根據應用情況來說，是否滿足手動指定document id的前提：
一般來說，是從某些其他的系統中，導入一些數據到es時，會採取這種方式，就是使用系統中已有數據的唯一標識，作爲es中document的id。舉個例子，比如說，我們現在在開發一個電商網站，做搜索功能，或者是OA系統，做員工檢索功能。這個時候，數據首先會在網站系統或者IT系統內部的數據庫中，會先有一份，此時就肯定會有一個數據庫的primary key（自增長，UUID，或者是業務編號）。如果將數據導入到es中，此時就比較適合採用數據在數據庫中已有的primary key。
如果說，我們是在做一個系統，這個系統主要的數據存儲就是es一種，也就是說，數據產生出來以後，可能就沒有id，直接就放es一個存儲，那麼這個時候，可能就不太適合說手動指定document id的形式了，因爲你也不知道id應該是什麼，此時可以採取下面要講解的讓es自動生成id的方式。
語法：put /index/type/id
2.自動生成document id（自動生成的id，長度爲20個字符，URL安全，base64編碼，GUID，分佈式系統並行生成時不可能會發生衝突）
語法：post /index/type
1、_source元數據：_source元數據：就是說，我們在創建一個document的時候，使用的那個放在requestbody中的json串，默認情況下，在get的時候，會原封不動的給我們返回回來。
_version元數據：控制併發衝突：內部如何基於_version進行樂觀鎖併發控制
第一次創建一個document的時候，它的_version內部版本號就是1；以後，每次對這個document執行修改或者刪除操作，都會對這個_version版本號自動加1；哪怕是刪除，也會對這條數據的版本號加1
刪除一個document之後，可以從一個側面證明，它不是立即物理刪除掉的，因爲它的一些版本號等信息還是保留着的。先刪除一條document，再重新創建這條document，其實會在delete version基礎之上，再把version號加1
悲觀鎖與樂觀鎖兩種併發控制方案
Elasticsearch併發衝突問題
external version
es提供了一個feature，就是說，你可以不用它提供的內部_version版本號來進行併發控制，可以基於你自己維護的一個版本號來進行併發控制。舉個列子，加入你的數據在mysql裏也有一份，然後你的應用系統本身就維護了一個版本號，無論是什麼自己生成的，程序控制的。這個時候，你進行樂觀鎖併發控制的時候，可能並不是想要用es內部的_version來進行控制，而是用你自己維護的那個version來進行控制。
?version=1
?version=1&version_type=external
version_type=external，唯一的區別在於，_version，只有當你提供的version與es中的_version一模一樣的時候，纔可以進行修改，只要不一樣，就報錯；當version_type=external的時候，只有當你提供的version比es中的_version大的時候，才能完成修改
es，_version=1，?version=1，才能更新成功
es，_version=1，?version>1&version_type=external，才能成功，比如說?version=2&version_type=external
external version
es提供了一個feature，就是說，你可以不用它提供的內部_version版本號來進行併發控制，可以基於你自己維護的一個版本號來進行併發控制。舉個列子，加入你的數據在mysql裏也有一份，然後你的應用系統本身就維護了一個版本號，無論是什麼自己生成的，程序控制的。這個時候，你進行樂觀鎖併發控制的時候，可能並不是想要用es內部的_version來進行控制，而是用你自己維護的那個version來進行控制。
?version=1
?version=1&version_type=external
version_type=external，唯一的區別在於，_version，只有當你提供的version與es中的_version一模一樣的時候，纔可以進行修改，只要不一樣，就報錯；當version_type=external的時候，只有當你提供的version比es中的_version大的時候，才能完成修改
es，_version=1，?version=1，才能更新成功
es，_version=1，?version>1&version_type=external，才能成功，比如說?version=2&version_type=external
time_out:
GET /_search
{
"took": 6,
"timed_out": false,
"_shards": {
"total": 6,
"successful": 6,
"failed": 0
},
"hits": {
"total": 10,
"max_score": 1,
"hits": [
{
"_index": ".kibana",
"_type": "config",
"_id": "5.2.0",
"_score": 1,
"_source": {
"buildNum": 14695
}
}
]
}
}
took：整個搜索請求花費了多少毫秒
hits.total：本次搜索，返回了幾條結果
hits.max_score：本次搜索的所有結果中，最大的相關度分數是多少，每一條document對於search的相關度，越相關，_score分數越大，排位越靠前
hits.hits：默認查詢前10條數據，完整數據，_score降序排序
shards：shards fail的條件（primary和replica全部掛掉），不影響其他shard。默認情況下來說，一個搜索請求，會打到一個index的所有primary shard上去，當然了，每個primary shard都可能會有一個或多個replic shard，所以請求也可以到primary shard的其中一個replica shard上去。
timeout：默認無timeout，latency平衡completeness，手動指定timeout，timeout查詢執行機制
timeout=10ms，timeout=1s，timeout=1m
GET /_search?timeout=10m