1.更新時(shí)的批量操作

就像mget允許我們一次性檢索多個(gè)文檔一樣，bulk?API允許我們使用單一請(qǐng)求來實(shí)現(xiàn)多個(gè)文檔的create、index、update或delete。這對(duì)索引類似于日志活動(dòng)這樣的數(shù)據(jù)流非常有用，它們可以以成百上千的數(shù)據(jù)為一個(gè)批次按序進(jìn)行索引。

bulk請(qǐng)求體如下，它有一點(diǎn)不同尋常：

這種格式類似于用"\n"符號(hào)連接起來的一行一行的JSON文檔流(stream)。兩個(gè)重要的點(diǎn)需要注意：

a.每行必須以"\n"符號(hào)結(jié)尾，包括最后一行。這些都是作為每行有效的分離而做的標(biāo)記。

b.例如刪除請(qǐng)求看起來像這樣：.每一行的數(shù)據(jù)不能包含未被轉(zhuǎn)義的換行符，它們會(huì)干擾分析——這意味著JSON不能被美化打印。

action/metadata這一行定義了文檔行為(what action)發(fā)生在哪個(gè)文檔(which document)之上。

行為(action)必須是以下幾種：

在索引、創(chuàng)建、更新或刪除時(shí)必須指定文檔的_index、_type、_id這些元數(shù)據(jù)(metadata)。

例如刪除請(qǐng)求看起來像這樣：

請(qǐng)求體(request body)由文檔的_source組成——文檔所包含的一些字段以及其值。它被index和create操作所必須，這是有道理的：你必須提供文檔用來索引。

這些還被update操作所必需，而且請(qǐng)求體的組成應(yīng)該與update?API（doc,?upsert,?script等等）一致。刪除操作不需要請(qǐng)求體(request body)。

如果定義_id，ID將會(huì)被自動(dòng)創(chuàng)建：

為了將這些放在一起，bulk請(qǐng)求表單是這樣的：

<1> 注意delete行為(action)沒有請(qǐng)求體，它緊接著另一個(gè)行為(action)

<2> 記得最后一個(gè)換行符

Elasticsearch響應(yīng)包含一個(gè)items數(shù)組，它羅列了每一個(gè)請(qǐng)求的結(jié)果，結(jié)果的順序與我們請(qǐng)求的順序相同：

<1> 所有子請(qǐng)求都成功完成。

每個(gè)子請(qǐng)求都被獨(dú)立的執(zhí)行，所以一個(gè)子請(qǐng)求的錯(cuò)誤并不影響其它請(qǐng)求。如果任何一個(gè)請(qǐng)求失敗，頂層的error標(biāo)記將被設(shè)置為true，然后錯(cuò)誤的細(xì)節(jié)將在相應(yīng)的請(qǐng)求中被報(bào)告：

響應(yīng)中我們將看到create文檔123失敗了，因?yàn)槲臋n已經(jīng)存在，但是后來的在123上執(zhí)行的index請(qǐng)求成功了：

<1> 一個(gè)或多個(gè)請(qǐng)求失敗。

<2> 這個(gè)請(qǐng)求的HTTP狀態(tài)碼被報(bào)告為409 CONFLICT。

<3> 錯(cuò)誤消息說明了什么請(qǐng)求錯(cuò)誤。

<4> 第二個(gè)請(qǐng)求成功了，狀態(tài)碼是200 OK。

這些說明bulk請(qǐng)求不是原子操作——它們不能實(shí)現(xiàn)事務(wù)。每個(gè)請(qǐng)求操作時(shí)分開的，所以每個(gè)請(qǐng)求的成功與否不干擾其它操作。

2.不要重復(fù)-批量檢索

你可能在同一個(gè)index下的同一個(gè)type里批量索引日志數(shù)據(jù)。為每個(gè)文檔指定相同的元數(shù)據(jù)是多余的。就像mget?API，bulk請(qǐng)求也可以在URL中使用/_index或/_index/_type:

你依舊可以覆蓋元數(shù)據(jù)行的_index和_type，在沒有覆蓋時(shí)它會(huì)使用URL中的值作為默認(rèn)值：

3.多大才算太大？-批量請(qǐng)求的大小如何控制

整個(gè)批量請(qǐng)求需要被加載到接受我們請(qǐng)求節(jié)點(diǎn)的內(nèi)存里，所以請(qǐng)求越大，給其它請(qǐng)求可用的內(nèi)存就越小。有一個(gè)最佳的bulk請(qǐng)求大小。超過這個(gè)大小，性能不再提升而且可能降低。

最佳大小，當(dāng)然并不是一個(gè)固定的數(shù)字。它完全取決于你的硬件、你文檔的大小和復(fù)雜度以及索引和搜索的負(fù)載。幸運(yùn)的是，這個(gè)最佳點(diǎn)(sweetspot)還是容易找到的：

試著批量索引標(biāo)準(zhǔn)的文檔，隨著大小的增長(zhǎng)，當(dāng)性能開始降低，說明你每個(gè)批次的大小太大了。開始的數(shù)量可以在1000~5000個(gè)文檔之間，如果你的文檔非常大，可以使用較小的批次。

通常著眼于你請(qǐng)求批次的物理大小是非常有用的。一千個(gè)1kB的文檔和一千個(gè)1MB的文檔大不相同。一個(gè)好的批次最好保持在5-15MB大小間。