多大是太大了？
整個批量請求都需要由接收到請求的節點加載到內存中，因此該請求越大，其他請求所能獲得的內存就越少。 批量請求的大小有一個最佳值，大於這個值，性能將不再提升，甚至會下降。 但是最佳值不是一個固定的值。它完全取決於硬件、文檔的大小和複雜度、索引和搜索的負載的整體情況。
幸運的是，很容易找到這個 最佳點 ：通過批量索引典型文檔，並不斷增加批量大小進行嘗試。 當性能開始下降，那麼你的批量大小就太大了。一個好的辦法是開始時將 1,000 到 5,000 個文檔作爲一個批次, 如果你的文檔非常大，那麼就減少批量的文檔個數。
密切關注你的批量請求的物理大小往往非常有用，一千個 1KB 的文檔是完全不同於一千個 1MB 文檔所佔的物理大小。 一個好的批量大小在開始處理後所佔用的物理大小約爲 5-15 MB。
新建、索引和刪除文檔
新建、索引和刪除 請求都是 寫 操作， 必須在主分片上面完成之後才能被複制到相關的副本分片，如下圖所示 Figure 9, “新建、索引和刪除單個文檔”.
Figure 9. 新建、索引和刪除單個文檔
以下是在主副分片和任何副本分片上面 成功新建，索引和刪除文檔所需要的步驟順序：
- 客戶端向
Node 1發送新建、索引或者刪除請求。 - 節點使用文檔的
_id確定文檔屬於分片 0 。請求會被轉發到Node 3，因爲分片 0 的主分片目前被分配在Node 3上。 Node 3在主分片上面執行請求。如果成功了，它將請求並行轉發到Node 1和Node 2的副本分片上。一旦所有的副本分片都報告成功,Node 3將向協調節點報告成功，協調節點向客戶端報告成功。
在客戶端收到成功響應時，文檔變更已經在主分片和所有副本分片執行完成，變更是安全的。
有一些可選的請求參數允許您影響這個過程，可能以數據安全爲代價提升性能。這些選項很少使用，因爲Elasticsearch已經很快，但是爲了完整起見，在這裏闡述如下：
consistency
consistency，即一致性。在默認設置下，即使僅僅是在試圖執行一個_寫_操作之前，主分片都會要求 必須要有 規定數量(quorum)（或者換種說法，也即必須要有大多數）的分片副本處於活躍可用狀態，纔會去執行_寫_操作(其中分片副本可以是主分片或者副本分片)。這是爲了避免在發生網絡分區故障（network partition）的時候進行_寫_操作，進而導致數據不一致。_規定數量_即：
int( (primary + number_of_replicas) / 2 ) + 1
consistency 參數的值可以設爲 one （只要主分片狀態 ok 就允許執行_寫_操作）,all（必須要主分片和所有副本分片的狀態沒問題才允許執行_寫_操作）, 或 quorum 。默認值爲 quorum , 即大多數的分片副本狀態沒問題就允許執行_寫_操作。
注意，規定數量 的計算公式中 number_of_replicas 指的是在索引設置中的設定副本分片數，而不是指當前處理活動狀態的副本分片數。如果你的索引設置中指定了當前索引擁有三個副本分片，那規定數量的計算結果即：
int( (primary + 3 replicas) / 2 ) + 1 = 3
如果此時你只啓動兩個節點，那麼處於活躍狀態的分片副本數量就達不到規定數量，也因此您將無法索引和刪除任何文檔。
timeout
如果沒有足夠的副本分片會發生什麼？ Elasticsearch會等待，希望更多的分片出現。默認情況下，它最多等待1分鐘。 如果你需要，你可以使用 timeout 參數 使它更早終止： 100 100毫秒，30s 是30秒。
新索引默認有 1 個副本分片，這意味着爲滿足 規定數量 應該 需要兩個活動的分片副本。 但是，這些默認的設置會阻止我們在單一節點上做任何事情。爲了避免這個問題，要求只有當 number_of_replicas 大於1的時候，規定數量纔會執行。