ElasticSearch Index 速度優化 （官方翻譯）

使用Bulk請求進行Index

• Bulk請求將產生比單文檔index請求有更好的性能。至於Bulk請求中文檔數量的大小，建議使用單一節點單一分片進行測試，先試試看100個，而後200個，而後400這樣，每次進行翻倍測試，只要速度穩定了，也就是最合適的大小了。可是要注意一下，並非速度最合適了就OK，由於每次請求總的大小要進行一下控制。併發發送的時候，ES內存壓力會很大，必定要避免每次請求超過幾十兆，即使是這樣插入的性能更好（這個我踩過坑，我這測試超過10M，ES就不接受請求，直接拒絕了）。

使用多個節點或者多線程進行Index

• 通常來講一個線程，即使是使用了Bulk方式進行Index，也沒法達到ES集羣的瓶頸，因此爲了最大限度的利用集羣資源，使用多線程或者多進程的方式進行Index是一個很好的選擇。這樣不只最大程度利用了集羣資源，還幫助減小了fsync的成本。（這個fsync是什麼 意思我暫時也沒弄明白，後續補充）。
• 要注意一下TOO_MANY_REQUESTS (429) 相應（對應Java Client 則是EsRejectedExecutionException）, 這說明ES集羣已經跟不上你Index的速度了，使用一些適當的方式限制一下速度吧。（官方文檔說暫停Index一會或者使用隨機指數函數Backoff）。
• 相似Bulk Index 數量，多線程多進程Index也須要進行人工測試，直到找到一個合適線程數或者進程數。

增長refresh interval

• 默認的 index.refresh_interval 是1s，在index的時候若是沒有實時性檢索需求，建議能夠設置大一些，好比30S，若是不須要檢索，等index完成才進行檢索的話，能夠設置爲-1，也就是禁用，等完成index以後在調整回來。

禁用refresh，下降分片副本數

• 若是須要一次index大量數據，最好禁用refresh，也就是將refresh_interval設置爲-1，同時index.number_of_replicas 設置爲0，也就是不須要副本。儘管這樣會增長一些風險（真的很小很小），也就是在索引的時候可能致使數據丟失，可是這樣能夠大幅度增長索引速度，等完成索引後在增長副本，這樣也能夠保證數據的可靠性。

禁用Swapping

• 必定確保操做系統禁用了swapping，這對ES性能有很大的提高。

給足夠的內存文件系統緩存

• 你應該分配機器的一半內存給ES使用，用於文件系統的緩存。文件系統緩存用於緩衝I/O操做。

使用系統自動生成id

• 當你index一個document使用特定的id，ES須要去檢查是否在同一個shard存在相同的ID的文檔，這是一個至關昂貴的操做，而且隨着文檔數量的增長，花費呈指數增加。若是使用自動生成id，ES會跳過這個檢查，使得Index速度更快。

使用更快的硬件

• 若是I/O是瓶頸，那麼最好考慮爲文件系統提供更多內存或者購買更好的服務器。使用SSD硬盤能比通常的硬盤有更好的性能。另外儘可能使用本地存儲，不要考慮遠程存儲。也儘量不要考慮Amazon等虛擬化存儲，儘管比較簡單的使用，可是性能比本地存儲差不少。
• 還有要儘量冗餘副本，以免節點故障致使數據丟失。也能夠用快照備份還原進一步下降數據糗事風險。

Indexing 緩衝大小

若是節點僅僅是大量Index，確保每一個分片 indices.memory.index_buffer_size 大於512M，（儘管大於512M沒有什麼性能改善）。舉個例子，默認值是10%，也是說若是你設置的jvm大小是10G，那麼Index緩衝大小是1G，足以支撐2個shard的大量索引。

禁用 _field_names

• 簡單來講，若是你不須要運行exists查詢，那麼你就能夠禁用_field_names。