Document APIs 文檔接口
這一部分開始會簡短介紹 Elasticsearch 的資料複制模型，接下來會詳解介紹下面的增删改查接口（CRUD APIs）。
1. Single document APIs 單文檔操作接口
- Index API
- Get API
- Delete API
- Update API
2. Multi-document APIs 多文檔操作接口
- Multi Get API
- Bulk API
- Delete By Query API
- Update By Query API
- Reindex API
Reading and Writing documents 讀寫文檔
**Introduction 介紹**
在 Elasticsearch 中，每一個索引可以分片，而每一個分片可以有多個副本。當增加或删除文檔的時候，它的這些副本集需要同步複制，否則，會出現讀不同副本的資料結果傳回不一緻的情況。我們稱保持分片副本一緻性和處理分片副本讀取的過程為資料複制模型（data replication model）
Elasticsearch 的資料複制模型基于主備模型并且在微軟研究的PacificA論文中描述的非常清楚。模型是基于一個複制集中的單拷貝的主分片。其他拷貝被稱為複制分片。主分片作為所有索引操作的主入口。挑戰在于校驗并確定這些主分片正确有效。當主分片接收到一個索引操作請求，它同時要對對其他副本的複制操作負責。
**Basic write model 基本寫模型**
在 Elasticsearch 中每個索引操作根據路由規則首先被分解到一個複制集，通常基于文檔ID。一旦複制集被選中，操作會被直接轉發到這個複制集的主分片。主分片負責校驗操作或者轉發操作到其他副本。因為副本可能下線，主分片不需要将資料複制到所有副本。Elasticsearch 維護了一個可以接收操作的分片清單作為替代方案。這個清單被稱為in-sync副本被主節點持有。顧名思義，這組狀态“好”的分片拷貝，保證已經處理了所有已經被使用者确認的索引和删除操作。
**Failure handling 失敗處理**
索引的過程當中可能會發生任何意想不到的事情-盡管主節點運作良好，二磁盤崩潰，節點之間不能通信，以及一些配置丢失都可能導緻副本上的操作失敗。以上雖然很少發生，但主分片必須對此負責。
當主分片自己失敗的時候，持有主分片的節點會發送消息給Master。索引操作會等待（預設最多1分鐘）master重新選舉出一個副本為新的主分片。索引操作會被轉發到新的主分片處理。比較典型的是當持有主分片的節點因為網絡問題與叢集是回去聯系會出現這種情況。
**Basic read model 基本讀模型**
在 ElasticSearch 中，讀操作可能是非常輕量的根據ID查詢或是需要消耗大量CPU資源的複雜聚合查詢。主備模型的一個優點是它儲存全量資料在所有分片中。是以，任何一個 in-sync 拷貝都可以有效地服務于查詢操作。
當一個節點接收到讀取請求時，該節點負責将其轉發到儲存相關分片的節點，整理響應，并響應用戶端。我們稱該節點為該請求的協調節點。基本流程如下：
1. 分解讀取請求并解析到相關分片。注意由于大多數搜尋将發送到一個或多個索引，是以通常需要從多個分片中讀取資料，每個分片代表資料的不同子集。
2. 從分片複制集選擇一個分片的活躍拷貝，可以是主分片也可以是複制分片。預設情況下，ElasticSearch會使用 round-robin算法在分片拷貝中選擇。
3. 向選中的副本發送相應級别讀請求。
4. 整合結果并傳回。注意如果是基于ID的檢索，隻有一個分片相關，這一步會省略。
**Shard failures 分片錯誤**
當一個分片響應失敗，協調節點會發送消息到同一個副本集的另一個分片副本。重複的失敗會導緻無可用的分片副本。
為了確定快速響應，如果一個或多個分片響應失敗，如下 APIs 會傳回部分結果。
- [Search](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/search-search.html)
- [Multi Search](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/search-multi-search.html)
- [Bulk](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-bulk.html)
- [Multi Get](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-multi-get.html)
包含部分資料的響應仍然會傳回200 HTTP狀态碼。分片失敗會在timed_out 和 _shards 的響應頭資訊中展示。
**A few simple implications**
如下這些基本流程決定了 ElasticSearch 作為一個搜尋系統的如何讀寫。此外，因為讀寫請求并發執行，是以這兩個基本操作流程互相影響。
- 高效讀取
在正常操作下，每個相關複制集執行一次讀取操作。隻有在失敗的情況下，同一個分片的多個副本才會執行相同的搜尋。
- 閱讀未确認
由于首先執行主索引本地索引，然後執行複制請求，是以并發讀取情況下可能在看到了未确認的更改。
- 預設2拷貝
此模型包含兩份拷貝，可以做到容錯處理。這與其它基于仲裁的至少保留3份拷貝的機制不同。
**Failures**
The Tip of the Iceberg 冰山一角
本文檔提供了 ElasticSearch 如何處理資料的進階概述。當然還有很多很多其他特性。想_primay_term、叢集狀态釋出及主節點選舉在保持 ElasticSearch 正确有效運作起到了關鍵作用。此文檔同樣沒有覆寫重要或已知的bugs。我們認識到Github很難跟上，為了幫助大家對此保持了解，我們在我們的網站上維護一個專門的[彈性頁面](https://www.elastic.co/guide/en/elasticsearch/resiliency/current/index.html)。我們強烈建議閱讀。
Index API 索引 API
See
删除映射類型.
注：目前一個es的索引Index僅含一種type的資料即_doc,相似的資料希望放在同一個Index下的話，可以在mapping中增加一個類型字段解決，同一個Index下不同類型（業務）的資料字段個數及類型要基本一緻，保持索引資料的密集。
curl -X PUT "localhost:9200/twitter/_doc/1" -H 'Content-Type: application/json' -d'
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
' 結果如下：
{
"_index": "twitter",
"_type": "_doc",
"_id": "1",
"_version": 1,
"result": "created", #建立成功
"_shards": {
"total": 2, #兩個分片（一主、一副本）
"successful": 1, #索引操作在一個分片副本上成功執行，這裡是主分片
"failed": 0 # #沒有任何一個分片上的索引操作失敗，說明隻有一個分片（主分片）啟動了
},
"_seq_no": 0,
"_primary_term": 1
} **Automatic Index Creation 自動建立索引**
當執行索引操作的時候如果索引不存在自動建立，并使用 已經配置好的[索引模闆](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/indices-templates.html)。索引操作同時也會自動建立（如果不存在的話）一個動态映射文檔。預設情況下，如果有需要新的字段或對象會準備自動添加到映射定義中。有關映射定義的更多資訊，請檢視[映射](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/mapping.html)部分；有關手動更新映射的資訊，請參閱[修改映射](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/indices-put-mapping.html)API。
自動建立索引由action.auto_create_index配置控制。此配置預設為True，這意味着索引總是自動被建立的。自動建立索引可以設定為隻有比對特定格式的索引才允許自動建立索引，方法是将這些索引格式以逗号分隔配置。還可以通過在清單中的格式前面加上+或-來明确地允許和禁止。最後，通過将此設定更改為false，可以完全禁用它。 設定twitter,index10可以被自動建立，比對ind開頭的，忽略以index1開頭
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"persistent": {
"action.auto_create_index": "twitter,index10,-index1*,+ind*"
}
}
'
設定為不可以自動建立
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"persistent": {
"action.auto_create_index": "false"
}
}
'
預設配置，自動建立
curl -X PUT "localhost:9200/_cluster/settings" -H 'Content-Type: application/json' -d'
{
"persistent": {
"action.auto_create_index": "true"
}
}
' **Operation Type 操作類型**
索引操作允許"put-if-absent"操作，也可以接口 op_type 參數來強制進行建立操作。如果使用了create，如果一個文檔已經存在name建立操作會失敗。 curl -X PUT "localhost:9200/twitter/_doc/1?op_type=create" -H 'Content-Type: application/json' -d'
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
' 如果已經存在報錯： {
"error": {
"root_cause": [{
"type": "version_conflict_engine_exception",
"reason": "[1]: version conflict, document already exists (current version [1])",
"index_uuid": "tEuwvTUyRN6Szp5Kh6yqOQ",
"shard": "0",
"index": "twitter"
}],
"type": "version_conflict_engine_exception",
"reason": "[1]: version conflict, document already exists (current version [1])",
"index_uuid": "tEuwvTUyRN6Szp5Kh6yqOQ",
"shard": "0",
"index": "twitter"
},
"status": 409
} **Automatic ID Generation ID自動生成**
索引操作可以不指定id而被執行。這種情況下id會被自動生成。一般情況下，op_type會自動設定為 create。
curl -X POST "localhost:9200/twitter/_doc/" -H 'Content-Type: application/json' -d'
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
' 結果如下： {
"_index": "twitter",
"_type": "_doc",
"_id": "1voRtGoBVXq4m3oClq2T", ##自動生成的id
"_version": 1,
"result": "created",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 1, ##這裡_seq_no為1了，為什麼？
"_primary_term": 1
} **Optimistic concurrency control 樂觀并發控制**
索引操作可以使用最後一次查詢傳回的序列号seq_no和主術語primary_term作為參數修改指定版本if_seq_no=362&if_primary_term=2的資料。如果檢測到不比對，操作将導緻版本沖突異常和狀态代碼409。有關更多詳細資訊，請參閱樂觀并發控制[link](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/optimistic-concurrency-control.html)。 Routing 路由
預設路由機制基于id的hash到不同資料分片。可以在建立文檔的時候指定_routing來控制。比如按照使用者id來指定_routing，那麼這個id的相關資料都會路由的同一個分片，如果有些id的資料量比較大，有些id資料量比較小，那麼會導緻資料不均勻。 Distributed 分發
基于路由表索引操作會被導向到主分片，并且被持有這個分片的實際節點執行。主分片執行完操作後，如果需要的話，更新會被同步到相應的複制分片。
**Wait For Active Shards**
**Refresh 重新整理**
控制資料更新後對新的請求可以見行。[見](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-refresh.html)
**Noop Updates**
未完待續……
**Timeout**
執行索引操作時，配置設定給執行索引操作的主分片可能不可用。原因可能是主分片目前正在從網關恢複或正在重新定位。預設情況下，索引操作将在主分片上等待1分鐘，然後失敗并以錯誤響應。timeout參數可用于顯式指定等待的時間。下面是将其設定為5分鐘的示例：
curl -X PUT "localhost:9200/twitter/_doc/1?timeout=5m" -H 'Content-Type: application/json' -d'
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
'
**Versioning**
未完待續…… Get API 查詢API
API 允許通過 ID 擷取json文檔。如下： curl -X GET "localhost:9200/twitter/_doc/1" 結果如下： {
"_index": "twitter",
"_type": "_doc",
"_id": "1",
"_version": 1,
"_seq_no": 0,
"_primary_term": 1,
"found": true,
"_source": {
"user": "kimchy",
"post_date": "2009-11-15T14:12:12",
"message": "trying out Elasticsearch"
}
} 同樣允許使用HEAD檢查指定的資源是否存在，如下： curl -I "localhost:9200/twitter/_doc/1" 結果日下：
HTTP/1.1 200 OK
content-type: application/json; charset=UTF-8
content-length: 224
**Realtime 實時**
預設情況下，Get API是實時擷取的，且不受索引重新整理率的影響（資料在搜尋時即可見）。如果文檔已更新但尚未重新整理，則Get API将在适當位置發出重新整理調用，以使文檔可見。這還将使上次重新整理後更改的其他文檔可見。如果要禁用實時擷取，可以将 realtime 參數設定為false。
**Source filtering 資源過濾**
預設情況下，“擷取”操作傳回 _source 字段的内容，除非您使用了 stored_fields 參數或禁用了 _source 字段。您可以通過 _source 參數關閉 _source 檢索：
curl -X GET "localhost:9200/twitter/_doc/1?_source=false"
如果您隻需要完整 souce 中的一個或兩個字段，您可以使用包含和排除參數來包含或篩選您需要的字段。這對于大型文檔尤其有用，因為部分檢索可以節省網絡開銷。兩個參數都采用逗号分隔的字段清單或通配符表達式。例子：
curl -X GET "localhost:9200/twitter/_doc/1?_source_includes=*.id&_source_excludes=entities"
如果隻想指定包含的字段，可以使用較短的文法：
curl -X GET "localhost:9200/twitter/_doc/1?_source=*.id,retweeted"
**Stored Fields**
擷取操作允許指定一組存儲字段，這些字段将通過傳遞 stored_fields 參數傳回。如果請求的字段未被存儲将忽略。例如如下映射：
curl -X PUT "localhost:9200/twitter" -H 'Content-Type: application/json' -d'
{
"mappings": {
"properties": {
"counter": {
"type": "integer",
"store": false
},
"tags": {
"type": "keyword",
"store": true
}
}
}
}
'
添加一個文檔：
curl -X PUT "localhost:9200/twitter/_doc/1" -H 'Content-Type: application/json' -d'
{
"counter" : 1,
"tags" : ["red"]
}
'
擷取這個文檔：
curl -X GET "localhost:9200/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"
]
}
}
還可以檢索中繼資料字段，如 _routing 字段：
curl -X PUT "localhost:9200/twitter/_doc/2?routing=user1" -H 'Content-Type: application/json' -d'
{
"counter" : 1,
"tags" : ["white"]
}
'
curl -X GET "localhost:9200/twitter/_doc/2?routing=user1&stored_fields=tags,counter"
結果如下：
{
"_index": "twitter",
"_type": "_doc",
"_id": "2",
"_version": 1,
"_seq_no": 1,
"_primary_term": 1,
"_routing": "user1",
"found": true,
"fields": {
"tags": ["white"]
}
}
此外，隻有葉子字段可以通過 stored_field 選項傳回。是以不能傳回對象字段，這樣的請求将失敗。
**Geting the _source directly 直接擷取_source資料**
使用 /{index}/_source/{id} endpoint 可以隻擷取文檔的source字段，例如：
curl -X GET "localhost:9200/twitter/_source/1"
結果如下：
{
"counter": 1,
"tags": ["red"]
}
**Routing 路由**
當索引使用使用路由控制表，為了擷取到資料，需要将 routing 參數加上。（注：路由是為了加快搜尋，避免了輪詢所有分片的）
curl -X GET "localhost:9200/twitter/_doc/2?routing=user1"
**Preference 設定**
未完待續……
**Refresh**
可以将refresh參數設定為true，以便在get操作之前重新整理相關的分片并使其可搜尋。将其設定為true應該在仔細考慮并驗證這不會導緻系統負載過重（并減慢索引速度）後進行。
**Distribuited 分發**
Get操作被散列到一個特定的shard id中，然後被重定向到該shard id的一個副本，并傳回結果。副本是主分片及其在該分片複制集中的副本。這意味着我們擁有的副本越多，我們将擁有更好的擴充能力。
**Versioning Support 版本支援**
curl -X GET "localhost:9200/twitter/_doc/2?version=1"
結果如下：
{"_index":"twitter","_type":"_doc","_id":"2","_version":1,"_seq_no":1,"_primary_term":1,"_routing":"user1","found":true,"_source":
{
"counter" : 1,
"tags" : ["white"]
}
}
在ElasticSearch内部，舊文檔被标記為已删除，并添加了一個全新的文檔。舊版本的文檔不會立即消失，盡管您将無法通路它。ElasticSearch 在繼續索引更多資料時在背景清除删除的文檔。
Delete API 删除API
curl -X DELETE "localhost:9200/twitter/_doc/1"
結果如下：
{
"_shards" : {
"total" : 2,
"failed" : 0,
"successful" : 2
},
"_index" : "twitter",
"_type" : "_doc",
"_id" : "1",
"_version" : 2,
"_primary_term": 1,
"_seq_no": 5,
"result": "deleted"
}
**Optimistic concurrency control 樂觀并發控制**
删除操作是有條件的，隻有在最後一次對文檔的修改被配置設定了if-seq-no和if-primary-term參數指定的序列号和主術語時才能執行。如果檢測到不比對項，操作将導緻版本沖突異常并傳回狀态代碼409。有關更多詳細資訊，請參閱[樂觀并發控制](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/optimistic-concurrency-control.html)。
**Versioning 版本**
索引的每個文檔都有版本控制。當删除文檔時，可以指定版本以確定我們要删除的相關文檔實際上已被删除，并且在此期間沒有更改。對文檔執行的每個寫入操作（包括删除）都會導緻其版本增加。删除後，已删除文檔的版本号在短時間内保持可用，以允許控制并發操作。已删除文檔的版本保持可用的時間長度由index.gc_删除索引設定确定，預設為60秒。
**Routing路由** 當索引使用了路由控制的功能時，為了删除文檔，還應該提供路由值。例如：
curl -X DELETE "localhost:9200/twitter/_doc/1?routing=kimchy"
上面将删除一條ID為1的tweet，但将根據使用者進行路由。請注意，如果沒有正确的發送路由，則發出“删除”指令将導緻文檔無法删除。
當 _routing 映射設定為必需且未指定路由值時，删除API将抛出RoutingMissingException并拒絕請求。
{
"_index": "twitter",
"_type": "_doc",
"_id": "1",
"_version": 2,
"result": "not_found",
"_shards": {
"total": 2,
"successful": 1,
"failed": 0
},
"_seq_no": 7,
"_primary_term": 2 }
**Automatic index creation 自動索引建立**
如果使用了外部版本控制變量，如果以前沒有建立過，則删除操作會自動建立索引（簽出用于手動建立索引的建立索引API）。
**Distributed 分發**
删除操作被散列到一個特定的分片 ID 中，然後被重定向到該分片集中的主分片中，并複制（如果需要）到該分片集中的分片副本中。
**Wait For Active Shards**
當發出删除請求時，可以将 wait_for_active_shards 參數設定最少分片副本活躍數。有關詳細資訊和用法示例，請參閱[此處](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-index_.html#index-wait-for-active-shards)。
**Refresh 重新整理**
控制此請求所做的更改對搜尋可見的時間。見[?refresh](https://www.elastic.co/guide/en/elasticsearch/reference/7.0/docs-refresh.html)
**Timeout 逾時**
當執行删除操作時，執行删除操作的主分片可能不可用。一些原因可能是主分片目前正在恢複或正在重新定位。預設情況下，删除操作将在主分片變為可用狀态前等待1分鐘，然後失敗并以錯誤響應。timeout參數可用于顯式指定等待的時間。下面是将其設定為5分鐘的示例：
curl -X DELETE "localhost:9200/twitter/_doc/1?timeout=5m" Delete By Query 根據查詢删除
curl -X POST "localhost:9200/twitter/_delete_by_query" -H 'Content-Type: application/json' -d'
{
"query": {
"match": {
"message": "some message"
}
}
}
'
結果如下：
{
"took" : 147,
"timed_out": false,
"deleted": 119,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"total": 119,
"failures" : [ ]
}
_delete_by_query 在索引啟動時擷取索引快照，并使用内部版本控制删除找到的内容。這意味着，如果文檔在拍攝快照和處理删除請求之間發生更改，則會出現版本沖突。隻有當當版本比對時，文檔才會被删除。
注：因為内部版本控制不支援将0值作為有效的版本号，是以版本為0的文檔不能使用 _delete_by_query 删除，并且将使請求失敗。
在 _delete_by_query 執行期間，将按順序執行多個搜尋請求，以查找所有比對的要删除的文檔。每次找到一批文檔時，都會執行相應的批量請求來删除所有這些文檔。如果搜尋或批量請求被拒絕，_delete_by_query 按照預設政策重試被拒絕的請求（最多10次，指數後退）。達到最大重試次數限制會導緻 _delete_by_query 中止，并在響應的 failures 傳回所有失敗。已執行的删除操作仍然保持不變。換句話說，程序不會復原，隻會中止。當第一個失敗導緻中止時，由失敗的批量請求傳回的所有失敗都會在failures 元素中傳回；是以，可能會有相當多失敗的實體。 If you’d like to count version conflicts rather than cause them to abort, then set conflicts=proceed on the url or "conflicts": "proceed" in the request body.
curl -X POST "localhost:9200/twitter/_delete_by_query?conflicts=proceed" -H 'Content-Type: application/json' -d'
"query": {
"match_all": {}
} '
結果如下:
"took": 115,
"timed_out": false,
"total": 1,
"deleted": 1,
"batches": 1,
"version_conflicts": 0,
"noops": 0,
"retries": {
"bulk": 0,
"search": 0
},
"throttled_millis": 0,
"requests_per_second": -1.0,
"throttled_until_millis": 0,
"failures": [] 删除多個索引資料，如下：
POST twitter,blog/_delete_by_query
"query": {
"match_all": {}
} 根據routing key指定分片下的資料：
If you provide routing then the routing is copied to the scroll query, limiting the process to the shards that match that routing value:
POST twitter/_delete_by_query?routing=1
"query": {
"range" : {
"age" : {
"gte" : 10
}
}
} By default _delete_by_query uses scroll batches of 1000. You can change the batch size with the scroll_size URL parameter:
POST twitter/_delete_by_query?scroll_size=5000
"query": {
"term": {
"user": "kimchy"
}
} **Url Parameters參數** 除了标準參數如pretty，delete by query api還支援refresh、wait_for_completion、wait_for_active_shards、timeout和scroll。
發送 refresh 将在請求完成後重新整理 _delete_by_query 中涉及的所有分片。這與delete api的refresh參數不同，後者隻會重新整理接收到删除請求的shard。與删除API不同，它不支援等待。
如果請求中包含wait_for_completion=false，那麼ElasticSearch将執行一些飛行前檢查，啟動請求，然後傳回可與任務API一起使用的任務，以取消或擷取任務的狀态。ElasticSearch還将在.tasks/task/$taskid處建立此任務的記錄作為文檔。這是您的，您可以根據需要保留或删除。完成後，删除它，這樣ElasticSearch可以回收它使用的空間。
wait_for_active_shards控制在繼續執行請求之前必須存在多少個活躍的shard副本。詳情請參閱
此處。timeout 控制每個寫請求等待不可用分片可用的時間。這兩種方法在批量API中的工作方式完全相同。由于“按查詢删除”使用scroll搜尋，您還可以指定scroll參數來控制“搜尋上下文”保持活動的時間，例如？scroll=10m。預設為5分鐘。
每秒請求書可以設定為任何正十進制數（1.4、6、1000等），并通過用等待時間間隔每個批來限制查詢删除請求操作的速率。通過将每秒請求數設定為-1，可以禁用門檻值。
### Response body 響應體
The JSON response looks like this:
{
"took" : 147, //整個操作消耗的毫秒數
"timed_out": false, //是否逾時
"total": 119, //比對總數
"deleted": 119, //删除總數
"batches": 1, //批次
"version_conflicts": 0, //版本沖突
"noops": 0, //This field is always equal to zero for delete by query. It only exists so that delete by query, update by query, and reindex APIs return responses with the same structure.
"retries": { //
"bulk": 0,
"search": 0
},
"throttled_millis": 0, //休眠時間
"requests_per_second": -1.0, //
"throttled_until_millis": 0, //This field should always be equal to zero in a _delete_by_query response. It only has meaning when using the Task API, where it indicates the next time (in milliseconds since epoch) a throttled request will be executed again in order to conform to requests_per_second.
"failures" : [ ] //失敗ids
} **Works with task API** curl -X GET "localhost:9200/_tasks?detailed=true&actions=*/delete/byquery"
結果如下：
{
"nodes" : {
"r1A2WoRbTwKZ516z6NEs5A" : {
"name" : "r1A2WoR",
"transport_address" : "127.0.0.1:9300",
"host" : "127.0.0.1",
"ip" : "127.0.0.1:9300",
"attributes" : {
"testattr" : "test",
"portsfile" : "true"
},
"tasks" : {
"r1A2WoRbTwKZ516z6NEs5A:36619" : {
"node" : "r1A2WoRbTwKZ516z6NEs5A",
"id" : 36619,
"type" : "transport",
"action" : "indices:data/write/delete/byquery",
"status" : {
"total" : 6154,
"updated" : 0,
"created" : 0,
"deleted" : 3500,
"batches" : 36,
"version_conflicts" : 0,
"noops" : 0,
"retries": 0,
"throttled_millis": 0
},
"description" : ""
}
}
}
}
} 使用task id可以直接檢視詳情：
curl -X GET "localhost:9200/_tasks/r1A2WoRbTwKZ516z6NEs5A:36619"
### Works with Cancel Task API
使用取消任務api可以取消查詢删除操作
curl -X POST "localhost:9200/_tasks/r1A2WoRbTwKZ516z6NEs5A:36619/_cancel"
取消操作會快速執行但是也需要幾秒的時間。Task清單API仍然會展示這個查詢删除操作直到他檢查到自己被取消并且終結自己。
**Rethrottling** 執行中的删除操作的requests_per_second值可以使用_rethrottle API修改，如下：
curl -X POST "localhost:9200/_delete_by_query/r1A2WoRbTwKZ516z6NEs5A:36619/_rethrottle?requests_per_second=-1"
就像在 delete by query API使用一樣，requests_per_second可以設定為-1來取消限流或者其他小數比如1.7或2來限制流量。提高速率可以立即生效，限制速率會在完成本批次以後生效。以上為了防止逾時。
**Slicing 切片** 查詢删除支援切片滾動的方式并行執行删除操作。這種并行化操作可以提高效率并且提供了一種便捷的方式将請求切分為一個個的小部分。
![Json 的三種解析方式Json簡介Json的三種解析方式[圖]](data:image/gif;base64,R0lGODlhAQABAIAAAP///wAAACwAAAAAAQABAAACAkQBADs=)