es官方文件解讀
PUT /customer?pretty 建立索引customer，返回json格式
GET /_cat/indices?v 列出所有索引列表
PUT /customer/doc/1?pretty 在客戶索引中插入資料（動詞 /索引[庫名]/型別[表名]/id?返回json格式的響應）
{
"name": "yufei"
}
Get /customer/doc/1?pretty 檢索編入的索引文件
*_source:指lucene的document，相當於資料庫表中的一行記錄
DELETE /customer?pretty 刪除索引
ElasticSearch訪問資料的模式:<REST動詞> / <索引> / <型別> / <ID>
*索引時，ID部分是可選的,如果未指定，Elasticsearch將生成隨機ID，然後使用它來索引文件。Elasticsearch生成的實際ID（或前面示例中顯式指定的內容）將作為索引API呼叫的一部分返回
*POST動詞而不是PUT，因為我們沒有指定ID
POST /customer/doc?pretty 插入資料沒有指定id時用動詞post,自動生成字串id(UUID)
{
"name": "Jane Doe"
}
更新文件：
*Elasticsearch實際上並沒有在內部進行就地更新。每當我們進行更新時，Elasticsearch都會刪除舊文件，然後一次性對應用了更新的新文件編制索引
更新之前的文件並加入欄位age
POST /customer/doc/1/_update?pretty 更新文件用動詞post,id後用_update
{
"doc": { "name": "Jane Doe", "age": 20 } 這兒的doc值lucene的docuemt，相當於資料庫表 中的一行記錄
}
也可以使用簡單指令碼執行更新。此示例使用指令碼將年齡增加5：
POST /customer/doc/1/_update?pretty
{
"script" : "ctx._source.age += 5"
}
在上面的示例中，ctx._source指的是即將更新的當前源文件。
Elasticsearch提供了在給定查詢條件（如SQL UPDATE-WHERE語句）的情況下更新多個文件的功能
*刪除文件 相當於刪除表中的一行記錄
DELETE /customer/doc/2?pretty 刪除文件用動詞delete
————————————————————————————————————————————————————————————————————————————————————
_bulkAPI批處理：用來多條執行上述操作
Bulk API不會因其中一個操作失敗而失敗。如果單個操作因任何原因失敗，它將繼續處理其後的其餘操作。批量API返回時，它將為每個操作提供一個狀態（按照發送的順序），以便您可以檢查特定操作是否失敗
POST /customer/doc/_bulk?pretty
{"index":{"_id":"3"}}
{"name": "John Doe" }
{"index":{"_id":"4"}}
{"name": "Jane Doe" }
對於刪除操作，之後沒有相應的源文件，因為刪除只需要刪除文件的ID。
POST /customer/doc/_bulk?pretty bulk批處理更新並刪除文件
{"update":{"_id":"1"}}
{"doc": { "name": "John Doe becomes Jane Doe" } }
{"delete":{"_id":"3"}}
——————————————————————————————————————————————————————————————————————————
樣本：
curl -H "Content-Type: application/json" -XPOST "localhost:9200/bank/doc/_bulk?pretty&refresh" --data-binary "@accounts.json"
curl "localhost:9200/_cat/indices?v"
————————————————————————————————Search API————————————————————————————————————————
1、請求以URL方法：
GET /bank/_search?q=*&sort=account_number:asc&pretty
動詞/索引/搜尋？匹配所有文件&升序進行排序
q=*引數指示Elasticsearch匹配索引中的所有文件。該sort=account_number:asc引數指示使用account_number每個文件的欄位以升序對結果進行排序。該pretty引數再次告訴Elasticsearch返回漂亮列印的JSON結果
返回結果刨析：
took - Elasticsearch執行搜尋的時間（以毫秒為單位）
timed_out - 告訴我們搜尋是否超時
_shards - 告訴我們搜尋了多少個分片，以及搜尋成功/失敗分片的計數
hits - 搜尋結果
hits.total - 符合我們搜尋條件的文件總數
hits.hits - 實際的搜尋結果陣列（預設為前10個文件）
hits.sort - 對結果進行排序（如果按分數排序則丟失）
hits._score並max_score- 暫時忽略這些欄位
2、不是傳入q=* url,採用_search API提供json格式的請求體
GET /bank/_search
{
"query": { "match_all": {} }, 匹配所有文件
"sort": [
{ "account_number": "asc" } 按account_number排序（升序）
]
}
一旦您獲得了搜尋結果，Elasticsearch就完全完成了請求，並且不會在結果中維護任何型別的伺服器端資源或開啟遊標。這與SQL等許多其他平臺形成鮮明對比，其中您可能最初預先獲得查詢結果的部分子集，然後如果要獲取（或翻頁）其餘的則必須連續返回伺服器使用某種有狀態伺服器端遊標的結果。
—————————————————————————————————————————— Query DSL——————————————————————————————————
GET / bank / _search
{
“query”：{“match_all”：{}} 搜尋所有文件
"size": 1 請注意，如果size未指定，則預設為10。實際搜尋的結果,返回前幾個文件
}
query部分告訴我們查詢定義是什麼，match_all部分只是我們想要執行的查詢型別。該match_all查詢僅僅是在指定索引的所有檔案進行搜尋
GET /bank/_search
{
"query": { "match_all": {} },
"from": 10, 返回文件10-19，用於分頁
"size": 10
}
在from（從0開始）引數規定了從啟動該檔案的索引和size引數指定了多少檔案，返回從引數開始的。在實現搜尋結果的分頁時，此功能非常有用。請注意，如果from未指定，則預設為0
GET / bank / _search 按賬戶餘額排序，返回前10個預設文件
{
“query”：{“match_all”：{}}，
“sort”：{“balance”： 排序欄位
{“order”：“desc”} 排序方式
}
}
————————————————————————————————————————————————————————————————————————————
搜尋返回指定欄位 返回兩個欄位account_number和balance（內部_source）
概念與SQL SELECT FROM欄位列表有些相似
GET /bank/_search
{
"query": { "match_all": {} },
"_source": ["account_number", "balance"]
}
———————————————————————match查詢針對特定欄位或欄位集進行的搜尋————————————————————————————————
返回編號為20的帳戶： match 指定要查詢的欄位
GET /bank/_search
{
"query": { "match": { "account_number": 20 } }
}
地址中包含術語“mill”或“lane”的所有帳戶 包含兩個元素用空格隔開 示例是match（match_phrase）的變體
GET /bank/_search
{
"query": { "match": { "address":"mill lane"}}
}
———————————————————————————————————bool查詢———————————————————————————————————————————————————————
使用布林邏輯將較小的查詢組成更大的查詢。
(1)bool must 必須兩這都包含，相當於sql中的and
此示例組成兩個match查詢並返回地址中包含“mill”和“lane”的所有帳戶：
GET /bank/_search
{
"query": {
"bool": {
"must": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
(2)bool should 滿足其中一個條件返回相當於sql中的or
GET /bank/_search
{
"query": {
"bool": {
"should": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
(3)bool must_not 既不包含A有不包含B，子句指定了一個查詢列表，對於文件而言，這些查詢都不能為真匹配
GET /bank/_search
{
"query": {
"bool": {
"must_not": [
{ "match": { "address": "mill" } },
{ "match": { "address": "lane" } }
]
}
}
}
總結：must should moust_not 是bool型，必須包含在bool內,多個條件條件用陣列包起來
返回任何40歲但不住在ID（aho）的人的所有帳戶：
GET /bank/_search
{
"query": {
"bool": {
"must": [
{ "match": { "age": "40" } }
],
"must_not": [
{ "match": { "state": "ID" } }
]
}
}
}
___________________________________________執行過濾器_____________________________________________________
range查詢：通常用於數字或日期過濾
使用bool查詢返回所有餘額介於20000和30000之間的帳戶。換句話說，我們希望找到餘額大於或等於20000且小於或等於30000的帳戶
GET /bank/_search
{
"query": {
"bool": {
"must": { "match_all": {} },
"filter": {
"range": {
"balance": {
"gte": 20000,
"lte": 30000
}
}
}
}
}
}
解析上面的內容，bool查詢包含match_all查詢（查詢部分）和range查詢（過濾部分）。我們可以將任何其他查詢替換為查詢和過濾器部分。在上面的情況中，範圍查詢非常有意義，因為落入範圍的文件都“相同”匹配，即，沒有文件比另一文件更相關
—————————————————————————————————————————————執行聚合—————————————————————————————————————————————————————
聚合提供了從資料中分組和提取統計資訊的功能。考慮聚合的最簡單方法是將其大致等同於SQL GROUP BY和SQL聚合函式。在Elasticsearch中，您可以執行返回匹配的搜尋，同時在一個響應中返回與命中相關的聚合結果。這是非常強大和高效的，因為您可以執行查詢和多個聚合，並一次性獲取兩個（或任一）操作的結果，避免使用簡潔和簡化的API進行網路往返。
此示例按狀態對所有帳戶進行分組，然後返回按計數降序排序的前10個（預設）狀態（也是預設值）：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword"
}
}
}
}
在SQL中，上述聚合在概念上類似於：
SELECT state, COUNT(*) FROM bank GROUP BY state ORDER BY COUNT(*) DESC
請注意，我們設定size=0為不顯示搜尋匹配，因為我們只希望在響應中看到聚合結果。
在前一個聚合的基礎上，此示例按州計算平均帳戶餘額（同樣僅針對按降序排序的前10個州）：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword"
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
請注意我們如何巢狀average_balance聚合內的group_by_state聚合。這是所有聚合的常見模式。您可以在聚合中任意巢狀聚合，以從資料中提取所需的輪轉摘要。
在前一個聚合的基礎上，我們現在按降序排列平均餘額：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_state": {
"terms": {
"field": "state.keyword",
"order": {
"average_balance": "desc"
}
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
此示例演示了我們如何按年齡段（20-29歲，30-39歲和40-49歲）進行分組，然後按性別分組，最後得到每個年齡段的平均帳戶餘額：
GET /bank/_search
{
"size": 0,
"aggs": {
"group_by_age": {
"range": {
"field": "age",
"ranges": [
{
"from": 20,
"to": 30
},
{
"from": 30,
"to": 40
},
{
"from": 40,
"to": 50
}
]
},
"aggs": {
"group_by_gender": {
"terms": {
"field": "gender.keyword"
},
"aggs": {
"average_balance": {
"avg": {
"field": "balance"
}
}
}
}
}
}
}
}
——————————————————————————————————————————————————安裝配置————————————————————————————————
要將Elasticsearch作為守護程式執行，請-d在命令列中指定，並使用以下-p選項將程序ID記錄在檔案中：
./bin/elasticsearch -d -p pid
可以在$ES_HOME/logs/目錄中找到日誌訊息。
要關閉Elasticsearch，請終止pid檔案中記錄的程序ID
kill `cat pid`
重要的Elasticsearch配置編輯
雖然Elasticsearch只需要很少的配置，但在投入生產之前需要考慮許多設定。
在投入生產之前，必須考慮以下設定：
路徑設定：
群集名稱：
cluster.name編輯
節點只能cluster.name在與群集中的所有其他節點共享群集時才能加入群集。預設名稱是elasticsearch，但您應將其更改為適當的名稱，該名稱描述了群集的用途。
cluster.name：logging-prod
確保不要在不同的環境中重用相同的群集名稱，否則最終會導致節點加入錯誤的群集
節點名稱：
node.name編輯
預設情況下，Elasticsearch將使用隨機生成的UUID的前七個字元作為節點id。請注意節點ID是持久的，並且在節點重新啟動時不會更改，因此預設節點名稱也不會更改。
值得配置一個更有意義的名稱，它還具有在重新啟動節點後保持永續性的優點：
node.name:prod-data-2
該node.name如下，也可以設定為伺服器的主機名：
node.name: $ {HOSTNAME}
網路主機：
network.host編輯
預設情況下，Elasticsearch僅繫結到環回地址 - 例如127.0.0.1 和[::1]。這足以在伺服器上執行單個開發節點。
實際上，可以從$ES_HOME 單個節點上的相同位置啟動多個節點。這對於測試Elasticsearch形成叢集的能力非常有用，但它不是推薦用於生產的配置。
為了與其他伺服器上的節點進行通訊並形成叢集，您的節點將需要繫結到非環回地址。雖然有許多 網路設定，但通常您需要配置的是 network.host：
network.host:192.168.1.10
該network.host設定也瞭解一些特殊的值，比如 _local_，_site_，_global_和喜歡修飾:ip4和:ip6，其中的細節中可以找到的特殊值network.host編輯。
發現設定：
Elasticsearch使用名為“Zen Discovery”的自定義發現實現進行節點到節點的群集和主選舉。在投入生產之前，應該配置兩個重要的發現設定。
discovery.zen.ping.unicast.hosts編輯
開箱即用，沒有任何網路配置，Elasticsearch將繫結到可用的環回地址，並將掃描埠9300到9305以嘗試連線到在同一伺服器上執行的其他節點。這提供了自動群集體驗，無需進行任何配置。
當需要在其他伺服器上形成具有節點的群集時，您必須提供群集中可能是實時且可聯絡的其他節點的種子列表。這可以指定如下：
discovery.zen.ping.unicast.hosts：
- 192.168.1.10:9300
- 192.168.1.11
- seeds.mydomain.com
如果未指定 ，埠將預設為transport.profiles.default.port和回退 transport.tcp.port。
解析為多個IP地址的主機名將嘗試所有已解析的地址。
discovery.zen.minimum_master_nodes編輯
為防止資料丟失，必須配置 discovery.zen.minimum_master_nodes設定，以便每個符合主節點的節點都知道必須可見的最大主節點數，才能形成叢集。
如果沒有此設定，遭受網路故障的群集可能會將群集拆分為兩個獨立的群集 - 分裂的大腦 - 這將導致資料丟失。在通過minimum_master_nodes編輯避免裂腦的過程中提供了更詳細的解釋 。
為避免分裂大腦，應將此設定設定為符合條件的主節點的法定數量：
（master_eligible_nodes / 2）+ 1
換句話說，如果有三個符合主節點的節點，則應將最小主節點設定為(3 / 2) + 1或2：
discovery.zen.minimum_master_nodes：2
堆大小：
堆轉儲路徑
GC記錄
——————————————————————————————————————日期數學索引名稱————————————————————————————————————————-
日期數學索引名稱解析使您可以搜尋一系列時間序列索引，而不是搜尋所有時間序列索引並過濾結果或維護別名。限制搜尋的索引數可以減少叢集上的負載並提高執行效能。例如，如果要在日常日誌中搜索錯誤，則可以使用日期數學名稱模板將搜尋限制為過去兩天。
幾乎所有具有index引數的API都支援index引數值中的日期數學。
日期數學索引名稱採用以下形式：
<static_name {date_math_expr {DATE_FORMAT |的time_zone}}>
static_name 是名稱的靜態文字部分
date_math_expr 是動態計算日期的動態日期數學表示式
date_format 是應該呈現計算日期的可選格式。預設為YYYY.MM.dd。
time_zone 是可選的時區。預設為utc。
您必須在尖括號中包含日期數學索引名稱表示式，並且所有特殊字元都應該是URI編碼的。例如：
# GET /<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
"query" : {
"match": {
"test": "data"
}
}
}
以下示例顯示了日期數學索引名稱的不同形式以及它們在給定當前時間時解析的最終索引名稱是2024年3月22日中午utc。
表達 解決了
<logstash-{now/d}>
logstash-2024.03.22
<logstash-{now/M}>
logstash-2024.03.01
<logstash-{now/M{YYYY.MM}}>
logstash-2024.03
<logstash-{now/M-1M{YYYY.MM}}>
logstash-2024.02
<logstash-{now/d{YYYY.MM.dd|+12:00}}>
logstash-2024.03.23
要使用索引名稱模板中的字元{和}靜態部分，請使用反斜槓對其進行轉義\，例如：
<elastic\\{ON\\}-{now/M}> 解決了 elastic{ON}-2024.03.01
以下示例顯示搜尋請求，該搜尋請求搜尋過去三天的Logstash索引，假設索引使用預設的Logstash索引名稱格式， logstash-YYYY.MM.dd。
# GET /<logstash-{now/d-2d}>,<logstash-{now/d-1d}>,<logstash-{now/d}>/_search
GET /%3Clogstash-%7Bnow%2Fd-2d%7D%3E%2C%3Clogstash-%7Bnow%2Fd-1d%7D%3E%2C%3Clogstash-%7Bnow%2Fd%7D%3E/_search
{
"query" : {
"match": {
"test": "data"
}
}
}
———————————————————————————————————————————————————返回值格式———————————————————————————————————————
漂亮的結果編輯
當附加?pretty=true到任何請求時，返回的JSON將被格式化（僅用於除錯！）。另一種選擇是設定?format=yaml哪個將導致以（有時）更可讀的yaml格式返回結果。
————————————————————————————————————————————————人類可讀的輸出——————————————————————————————————————
統計資訊以適合人類（例如"exists_time": "1h"或"size": "1kb"）和計算機（例如"exists_time_in_millis": 3600000或"size_in_bytes": 1024）的格式返回。可以通過新增?human=false 到查詢字串來關閉人類可讀取的值。當統計結果被監控工具消耗時，這是有意義的，而不是用於人類消費。human標誌的預設值是 false。
————————————————————————————————————————————————————響應過濾—————————————————————————————————————————————————
所有REST API都接受一個filter_path引數，該引數可用於減少Elasticsearch返回的響應。此引數採用逗號分隔的過濾器列表，用點表示法表示：
GET /_search?q=elasticsearch&filter_path=took,hits.hits._id,hits.hits._score
Elasticsearch有時會直接返回欄位的原始值，如_source欄位。如果要篩選_source欄位，則應考慮將已存在的_source引數（請參閱 獲取API以獲取更多詳細資訊）與以下filter_path 引數組合：
POST / library / book？refresh
{“title”：“Book＃1”，“rating”：200.1}
POST / library / book？refresh
{“title”：“Book＃2”，“rating”：1.7}
POST / library / book？refresh
{“title”：“Book＃3”，“rating”：0.1}
GET /_search?filter_path=hits.hits._source&_source=title&sort=rating:desc
———————————————————————————————————————————————平面設定—————————————————————————————————————————————
該flat_settings標誌會影響設定列表的呈現。當 flat_settings標誌被true設定返回在一個平面格式
———————————————————————————————————————————————基於URL的訪問控制————————————————————————————————————
許多使用者使用具有基於URL的訪問控制的代理來保護對Elasticsearch索引的訪問。對於多搜尋， 多重獲取和批量請求，使用者可以選擇在URL和請求正文中的每個單獨請求中指定索引。這可以使基於URL的訪問控制具有挑戰性。
要防止使用者覆蓋URL中指定的索引，請將此設定新增到elasticsearch.yml檔案中：
rest.action.multi.allow_explicit_index：false
預設值為true，但設定false為時，Elasticsearch將拒絕在請求正文中指定了顯式索引的請求。
———————————————————————————————————————————————文件API———————————————————————————————————————————————
1、單文件API
自動建立索引：
可以通過在所有節點的配置檔案中設定action.auto_create_index來禁用自動索引建立 false。通過將per-index 設定index.mapper.dynamic為false索引設定，可以禁用自動對映建立 。
自動索引建立可以包括基於模式的白/黑列表，例如，設定action.auto_create_index為+aaa*,-bbb*,+ccc*,-*（+表示允許， - 表示不允許）。
建立索引文件： 可以用_create也可以指定？op_type = create引數
PUT twitter/tweet/3/_create
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
自動生成ID:
可以在不指定id的情況下執行索引操作。在這種情況下，將自動生成id。此外，op_type 將自動設定為create。這是一個例子（注意使用 POST而不是PUT）：
POST twitter/tweet/
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
__________________________________________________________路由_________________________________
預設情況下，分片放置 - 或routing- 通過使用文件的id值的雜湊來控制。對於更明確的控制，可以使用routing引數在每個操作的基礎上直接指定輸入到路由器使用的雜湊函式的值。例如：
POST twitter/tweet?routing=kimchy
{
"user" : "kimchy",
"post_date" : "2009-11-15T14:12:12",
"message" : "trying out Elasticsearch"
}
在上面的示例中，“tweet”文件根據提供的routing引數路由到分片：“kimchy”。
設定顯式對映時，_routing可以選擇使用該欄位指示索引操作從文件本身提取路由值。這確實來自另一個文件解析過程的（非常小的）成本。如果_routing對映已定義並設定為required，則如果未提供或提取路由值，則索引操作將失敗。
———————————————————————————————————————————Noop更新—————————————————————————————————————————
使用索引api更新文件時，即使文件未更改，也始終會建立新版本的文件。如果這是不可接受的，請使用設定為true 的_updateapi detect_noop。索引api上沒有此選項，因為索引api不會獲取舊源，也無法將其與新源進行比較。
關於何時不接受noop更新，沒有一條硬性規定。它是許多因素的組合，例如您的資料來源傳送實際noops更新的頻率以及Elasticsearch在接收更新時在分片上執行的每秒查詢數。
——————————————————————————————————————————————Get API————————————————————————————————————
get API允許根據其id從索引中獲取型別化的JSON文件。以下示例從名為twitter的索引中獲取一個JSON文件，該索引名為tweet，id值為0：
獲取twitter / tweet / 0
API還允許使用以下方式檢查文件是否存在 HEAD：
HEAD twitter / tweet / 0
實時：
預設情況下，get API是實時的，並且不受索引重新整理率的影響（當資料對搜尋可見時）。如果文件已更新但尚未重新整理，則get API將就地發出重新整理呼叫以使文件可見。這也將使上次重新整理後其他文件發生變化。為了禁用實時GET，可以將realtime引數設定為false。
源過濾:
預設情況下，get操作返回_source欄位的內容，除非您已使用該stored_fields引數或該_source欄位已禁用。您可以_source使用以下_source引數關閉檢索
GET twitter/tweet/1?_source=false 返回的json沒有_source源
如果您只需要完整的一個或兩個欄位，則_source可以使用_source_include ＆_source_exclude引數來包含或過濾掉您需要的部分。這對於大型文件尤其有用，其中部分檢索可以節省網路開銷。這兩個引數都使用逗號分隔的欄位列表或萬用字元表示式。例：
GET twitter/tweet/1?_source_include=*.id&_source_exclude=entities
如果您只想指定包含，則可以使用較短的表示法：
GET twitter/tweet/0?_source=*.id,retweeted
—————————————————————————————————————————————儲存欄位————————————————————————————————————————————————————
get操作允許指定將通過傳遞stored_fields引數返回的一組儲存欄位。如果未儲存請求的欄位，則將忽略它們。例如，考慮以下對映：
PUT twitter
{
"mappings": {
"tweet": {
"properties": {
"counter": {
"type": "integer",
"store": false
},
"tags": {
"type": "keyword",
"store": true
}
}
}
}
}
現在我們可以新增一個文件：
PUT twitter/tweet/1
{
"counter" : 1,
"tags" : ["red"]
}
只有葉子欄位可以通過stored_field選項返回。因此無法返回物件欄位，此類請求將失敗
——————————————————————————————————————————獲取_source直接——————————————————————————————————————————————————
使用/{index}/{type}/{id}/_source端點只獲取_source文件的欄位，而不包含任何其他內容。例如
GET twitter/tweet/1/_source
您還可以使用相同的源過濾引數來控制_source將返回的部分：
GET twitter/tweet/1/_source?_source_include=*.id&_source_exclude=entities'
_source端點還有一個HEAD變體，可以有效地測試document _source的存在。如果在對映中禁用了現有文件，則該文件將沒有_source 。
HEAD twitter / tweet / 1 / _source
使用控制路由的能力進行索引時，為了獲取文件，還應提供路由值。例如：
GET twitter/tweet/2?routing=user1
以上將獲得id為2的推文，但將根據使用者進行路由。注意，在沒有正確路由的情況下發出get，將導致無法獲取文件。
————————————————————————————————————————————Delete API————————————————-----——————————————————————
delete API允許根據其id從特定索引中刪除型別化的JSON文件。以下示例從名為twitter的索引中刪除JSON文件，該索引名為tweet，id為1：
DELETE / twitter / tweet / 1
版本控制編輯
索引的每個文件都是版本化的。刪除文件時，version可以指定以確保我們嘗試刪除的相關文件實際上已被刪除，並且在此期間沒有更改。對文件執行的每個寫入操作（包括刪除）都會導致其版本遞增。刪除文件的版本號在刪除後仍可短時間使用，以便控制併發操作。已刪除文件的版本保持可用的時間長度由index.gc_deletes索引設定決定，預設為60秒。
______________________________________Delete By Query API________________________________________________
最簡單的用法是_delete_by_query對匹配查詢的每個文件執行刪除操作。這是API
POST twitter/_delete_by_query 相當於delete.....where.....
{
"query": {
"match": {
"message": "some message"
}
}
}
必須query以與Search API相同的方式將查詢作為值傳遞給鍵。您也可以使用q 與搜尋API相同的方式使用引數。
_delete_by_query在索引啟動時獲取索引的快照，並使用internal版本控制刪除它找到的內容。這意味著如果文件在拍攝快照的時間和處理刪除請求之間發生更改，則會出現版本衝突。當版本匹配時，文件將被刪除。
在_delete_by_query執行期間，順序執行多個搜尋請求以便找到要刪除的所有匹配文件。每次找到一批文件時，都會執行相應的批量請求以刪除所有這些文件。如果搜尋或批量請求被拒絕，則_delete_by_query 依賴於預設策略來重試被拒絕的請求（最多10次，指數後退）。達到最大重試次數限制會導致_delete_by_query 中止，並failures在響應中返回所有失敗。已執行的刪除仍然有效。換句話說，該過程不會回滾，只會中止。當第一個失敗導致中止時，失敗的批量請求返回的所有失敗都將返回到failures 元件; 因此，可能存在相當多的失敗實體。
如果您想計算版本衝突而不是讓它們中止，那麼請conflicts=proceed在URL或"conflicts": "proceed"請求正文中設定。
回到API格式，您可以限制_delete_by_query為單一型別。這隻會tweet從twitter索引中刪除文件
POST twitter/tweet/_delete_by_query?conflicts=proceed
{
"query": {
"match_all": {}
}
}
也可以一次刪除多個索引和多個型別的文件，就像搜尋API一樣：
POST twitter,blog/tweet,post/_delete_by_query
{
"query": {
"match_all": {}
}
}
——————————————————————————————————————————————Task API—————————————————————————————————————————————————
GET _tasks?detailed=true&actions=*/delete/byquery
該物件包含實際狀態。它就像響應json一樣，重要的是增加了這個total領域。total是reindex期望執行的操作總數。您可以通過新增估計的進展updated，created以及deleted多個領域。請求將在其總和等於total欄位時結束。
————————————————————————————————————————————————Update API————————————————————————————————————————————————
讓我們索引一個簡單的文件
PUT test/type1/1
{
"counter" : 1,
"tags" : ["red"]
}
現在，我們可以執行一個增加計數器的指令碼：
POST test/type1/1/_update
{
"script" : {
"source": "ctx._source.counter += params.count",
"lang": "painless",
"params" : {
"count" : 4
}
}
}
我們還可以在文件中新增一個新欄位：
POST test/type1/1/_update
{
"script" : "ctx._source.new_field = 'value_of_new_field'"
}
或者從文件中刪除欄位：
POST test/type1/1/_update
{
"script" : "ctx._source.remove('new_field')"
}
而且，我們甚至可以改變執行的操作。如果tags欄位包含green，此示例將刪除doc ，否則它不執行任何操作（noop）：
POST test/type1/1/_update
{
"script" : {
"source": "if (ctx._source.tags.contains(params.tag)) { ctx.op = 'delete' } else { ctx.op = 'none' }",
"lang": "painless",
"params" : {
"tag" : "green"
}
}
}
部分文件更新：
更新API還支援傳遞部分文件，該部分文件將合併到現有文件中（簡單的遞迴合併，物件的內部合併，替換核心“鍵/值”和陣列）。例如：
POST test/type1/1/_update
{
"doc" : {
"name" : "new_name"
}
}
如果同時doc和script指定，然後doc被忽略。最好是將部分文件的欄位對放在指令碼本身中。
Uperts：
如果文件尚不存在，則upsert元素的內容將作為新文件插入。如果文件確實存在，那麼 script將執行：
POST test/type1/1/_update
{
"script" : {
"source": "ctx._source.counter += params.count",
"lang": "painless",
"params" : {
"count" : 4
}
},
"upsert" : {
"counter" : 1
}
}
—————————————————————————————————————————Update By Query API—————————————————————————————————————————————
按查詢API更新:
最簡單的用法是_update_by_query在不更改源的情況下對索引中的每個文件執行更新。這對於獲取新屬性或其他一些線上對映更改很有用 。這是API：
POST twitter / _update_by_query？conflicts = proceed
您還可以_update_by_query使用 Query DSL進行限制。這將更新twitter使用者索引中的所有文件 kimchy：
POST twitter/_update_by_query?conflicts=proceed
{
"query": {
"term": {
"user": "kimchy"
}
}
}
您可以使用Task API獲取所有正在執行的逐個查詢請求的狀態 ：
GET _tasks？detailed = true＆actions = * byquery
____________________________________Multi Get API____________________________________________________
Multi GET API允許基於索引，型別（可選）和id（以及可能的路由）獲取多個文件。響應包括一個docs陣列，其中所有獲取的文件按順序對應於原始的多重獲取請求（如果特定獲取失敗，則包含此錯誤的物件將包含在響應中）。成功獲取的結構在結構上類似於get API 提供的文件 。
GET /_mget 此處用_mget
{
"docs" : [
{
"_index" : "test",
"_type" : "type",
"_id" : "1"
},
{
"_index" : "test",
"_type" : "type",
"_id" : "2"
}
]
}
mget端點也可以針對索引（在這種情況下它不能在體內所需的）中使用：
GET /test/_mget
{
"docs" : [
{
"_type" : "type",
"_id" : "1"
},
{
"_type" : "type",
"_id" : "2"
}
]
}
———————————————————————————————————————————————————————批量API—————————————————————————————————————
批量API使得在單個API呼叫中執行許多索引/刪除操作成為可能。這可以大大提高索引速度
以下是批量命令的正確序列示例：
POST _bulk
{ "index" : { "_index" : "test", "_type" : "type1", "_id" : "1" } }
{ "field1" : "value1" }
{ "delete" : { "_index" : "test", "_type" : "type1", "_id" : "2" } }
{ "create" : { "_index" : "test", "_type" : "type1", "_id" : "3" } }
{ "field1" : "value3" }
{ "update" : {"_id" : "1", "_type" : "type1", "_index" : "test"} }
{ "doc" : {"field2" : "value2"} }