[TOC] 2、GET API get API 可以通過文檔id從索引中獲取json格式的文檔，以下示例從 索引中獲取 為`_doc`，id值為0為的JSON文檔： 返回結果： 上述返回結果包含文檔的_index, _type, _id 和_version 欄位。如果 欄位為 , 就會返回 欄位，即 ...
2、GET API
get API 可以通過文檔id從索引中獲取json格式的文檔，以下示例從twitter索引中獲取type為_doc，id值為0為的JSON文檔：
GET twitter/_doc/0返回結果：
{
"_index" : "twitter",
"_type" : "_doc",
"_id" : "0",
"_version" : 1,
"_seq_no" : 10,
"_primary_term" : 1,
"found": true,
"_source" : {
"user" : "kimchy",
"date" : "2009-11-15T14:12:12",
"likes": 0,
"message" : "trying out Elasticsearch"
}
}上述返回結果包含文檔的_index, _type, _id 和_version 欄位。如果 found 欄位為ture, 就會返回_source欄位，即文檔內容。
這個API 可以使用HEAD方法查詢文檔是否存在：
HEAD twitter/_doc/02.1 實時（Realtime）
get API 預設是實時的，不會受索引刷新率影響（即數據從索引到搜索時可見的那個延遲時間）。如果文檔已更新但還沒刷新，get API將在適當位置發出刷新調用，這還將使上次刷新後更改的其他文檔可見。為了禁用get API的實時性，你可以設置 realtime=false。
2.2 文檔過濾（Source filtering）
get操作預設會返回_source欄位的內容，如果你不想返回該欄位，可以使用stored_fields或_source參數設置為false。
GET twitter/_doc/0?_source=false如果你僅僅需要返回一個或兩個欄位，你可以使用_source_include 和 _source_exclude參數來包含或篩選你需要的欄位。這對於大型文檔尤其有用，因為這樣可以降低網路開銷。兩個參數都採用逗號分隔的欄位列表或通配符表達式：
GET twitter/_doc/0?_source_includes=*.id&_source_excludes=entities你也可以使用_source參數指定要返回的欄位：
GET twitter/_doc/0?_source=*.id,retweeted2.3 已保存的欄位（Stored Fields）
mappings中的store=false 是為了減少存儲的欄位（如果要使用store_fields,你應該要禁用_source，即不保存源文檔，如果你開啟了_source那麼stored_fileds就沒什麼用途了，stored_fileds就像sphinx的屬性一樣用於搜索，而_source就是資料庫的數據，一般為了節省記憶體都不會存儲所有欄位，只存儲需要搜索的欄位，或者只存儲id）。
get操作指定一組stored_fields用於獲取已存儲的欄位（預設不會存儲欄位值，但可以搜索出文檔id，你需要在mappings中指定store=true）。如果請求欄位沒有被存儲（即欄位的store=false），他們將會被忽略。例如，考慮如下的mappings：
PUT twitter
{
"mappings": {
"_doc": {
"properties": {
"counter": {
"type": "integer",
"store": false
},
"tags": {
"type": "keyword",
"store": true
}
}
}
}
}現在我們添加一個文檔
PUT twitter/_doc/1
{
"counter" : 1,
"tags" : ["red"]
}然後訪問他：
GET twitter/_doc/1?stored_fields=tags,counter上述操作的結果：
{
"_index": "twitter",
"_type": "_doc",
"_id": "1",
"_version": 1,
"_seq_no" : 22,
"_primary_term" : 1,
"found": true,
"fields": {
"tags": [
"red"
]
}
}已存儲的欄位值會以fields數組形式返回。因為counter欄位的stored為false，所以GET時會被忽略。
也可以用_routing檢索元數據欄位：
PUT twitter/_doc/2?routing=user1
{
"counter" : 1,
"tags" : ["white"]
}GET twitter/_doc/2?routing=user1&stored_fields=tags,counter響應結果：
{
"_index": "twitter",
"_type": "_doc",
"_id": "2",
"_version": 1,
"_seq_no" : 13,
"_primary_term" : 1,
"_routing": "user1",
"found": true,
"fields": {
"tags": [
"white"
]
}
}使用stored_field選項，僅僅葉子（即基礎數據類型）欄位值會被返回，對象類型的欄位值不能返回，當要求返回對象類型的欄位值會報錯。
2.4 直接獲取_source（Getting the _source directly）
用/{index}/{type}/{id}/_source API可以僅獲取文檔的_source欄位，而不會獲取其他額外的信息，如：
GET twitter/_doc/1/_source你可以指定需要返回的欄位
GET twitter/_doc/1/_source?_source_includes=*.id&_source_excludes=entities你也可以用_source_include和_source_exclude欄位控制_source返回哪些欄位，不返回哪些欄位：
GET twitter/tweet/1/_source?_source_include=*.id&_source_exclude=entities' 你也可以使用HEAD API查詢某個文檔的_source是否存在（如果在mappings的禁用_source，文檔將不會保存源數據）。
HEAD twitter/_doc/1/_source2.5 路由（Routing）
當Index的時候指定了routing參數，為了得到指定的文檔，你Get的時候也需要指定同樣的routing參數：
GET twitter/_doc/2?routing=user1以上將根據user1進行路由獲得id為2的文檔。請註意，在沒有正確路由的情況下get操作將不會得到正確的結果。
2.6 首選分片（Preference）
preference參數可以控制在哪個分片上優先執行get請求。預設是在主分片與副本分片之間隨機查詢的。
preference`可以設置為：
- _primary
- get 請求只在主分片執行
- _local
- get 請求儘可能地在本地分配的分片上執行
- 自定義（字元串）值
- 同一個自定義的值將會訪問同一個分片。這使得你的數據訪問具有一致性，例如第一次訪問副本分片，然後主分片的數據發生變化，但副本分片還沒來得及更新；此時，第二次訪問的是主分片，將獲取到新的數據；第三次訪問的是副本分片時獲取的數據卻是舊數據。為了避免這種情況，你可以指定一個自定義的值，例如用戶名或sessionid，使隨後每次訪問的分片都和第一次訪問的分片一樣。
2.7 刷新（Refresh）
為了在get操作之前刷新相關的分片並使其可被搜索，可以將refresh參數設置為true。將其設置為true之前你應該在仔細考慮並驗證這會不會導致系統負載過重（並減慢索引速度）
2.8 分散式（Distributed）
get操作會通過hash路由到一個指定的分片id上執行，然後被重定向到該shard id中的一個副本（即副本分片和主分片是等價的，elasticsearch遵循對等協議），最後選擇其中的一個作為實際查詢的分片。這意味著我們擁有的副本分片越多，擴展性就越好。
2.9 版本支持（Versioning support）
你可以指定version參數用來獲取version值和指定參數值一致的文檔。對於所有版本類型，此行為都相同，但始終檢索文檔的版本類型force除外。請註意，force版本類型已棄用。
當你更新文檔時，elasticsearch 會標記舊版本的文檔為刪除狀態，並使其不能被查詢到，然後再創建一個新的文檔。也就是說舊版本的文檔不會立即消失，但您將無法訪問它。當您繼續索引更多數據時，Elasticsearch會在後臺清除具有刪除標記的文檔。
