索引速率調優 · Elasticsearch 5.4 中文文檔

# 索引速率調優原文鏈接 : [https://www.elastic.co/guide/en/elasticsearch/reference/5.3/tune-for-indexing-speed.html](https://www.elastic.co/guide/en/elasticsearch/reference/5.3/tune-for-indexing-speed.html) 譯文鏈接 :?[索引速率調優](/pages/viewpage.action?pageId=10027117) 貢獻者 : @李堅，[ApacheCN](/display/~apachecn)，[Apache中文網](/display/~apachechina) ## 使用批量請求 _Bulk requests（批量請求）_會比單文檔索引請求性能更優。確認_bulk requests（?批量請求）_的最佳大小，要在單個節點上使用單個分片進行基準測試來獲取。首先嘗試一次性索引 100 個 _documents（文檔）_，然后200個，然后400個；在每個基準測試中，下一次索引的 documents（文檔）數是上一次的兩倍。當索引速率達到最高時，就可以確認每次 _bulk requests（?批量請求）_的最佳 _documents（文檔）_數大小了。在領帶情況下，最好是發生的錯誤越少越好而不是索引的_documents（文檔）_越多越好。當心，很多客戶端同時發送數據產生非常大的 _bulk requests（?批量請求）_使集群處在內存壓力下；即使看起來較大的請求會更好，還是建議每個請求不要超出幾十兆字節。 ## 使用多線程向Elasticsearch發送數據單線程的 _bulk requests（?批量請求）_達不到 _Elasticsearch_ 集群的最大索引性能。為了充分利用集群的資源，應該使用多個線程或進程發送數據。除了更好地利用集群的資源外，這也有助于降低每個 fsync 的成本。當你看到**_TOO_MANY_REQUESTS（429）_**響應代碼（_EsRejectedExecutionException with the Java client_），這是 _Elasticsearch_ 告訴您無法跟上當前索引速率了。當這種情況發生的時候，先暫停索引一會，然后再次嘗試， ideally?with?randomized?exponential?backoff（理論上會有隨機指數回退）。類似于調整_ bulk requests（?批量請求）_的大小，只有通過測試才可以知道最適合的線程數。這個可以通過逐漸增加線程的數量進行測試，直到集群上的 _I / O 或 CPU_ 飽和為止。 ## 增大刷新間隔默認 ?_[`index.refresh_interval`](https://www.elastic.co/guide/en/elasticsearch/reference/5.3/index-modules.html#dynamic-index-settings "Dynamic index settingsedit")_ 是 1s，它將強制 _Elasticsearch_ 每秒創建一個新的 _segment_ ，增加這個值（比如 30s），允許生成較大的 _segment_ 再刷新，將會減少將來合并的壓了。? ## 禁用初始加載的刷新和副本如果需要一次加載大量的數據，禁用刷新功能和副本通過設置 _`index.refresh_interval`_ 為 `-1` 并且設置 _`index.number_of_replicas`_ 為 `0`。這將暫時使您的索引處于風險之中，因為丟失任何_ shard（分片）_會導致數據丟失，但與此同時索引的更快，因為文檔將僅被索引一次。一旦初始化加載完成，就可以把 _`index.refresh_interval`_?和_ `index.number_of_replicas` _改回正常值。 ## 禁用swapping 通過禁用交換分區來確保操作系統沒有交換出java進程。 ## 給文件系統緩存提供內存文件系統緩存將用于緩沖 I / O 操作。您應該確保至少將運行 _Elasticsearch_ 的機器內存的至少一半提供給文件系統緩存。 ## 使用自動生成的id 當索引一個帶有 _id_ 的 _document （文檔）_時，_Elasticsearch_ 要檢查在相同的 _shard（分片）_上是否還有相同 _id_ 的 _document （文檔）_存在，這個操作需要的花費很大，隨著索引的增長操作需要的花費將會越來越大。通過使用自動生成的_id_，_Elasticsearch_ 可以跳過此檢查，這使索引更快。 ## 使用更快的硬件如果索引受限于 _**I/O**_ ，應該增加文件系統緩存的內存（見上文）或者購買更快的驅動設備。特別是 _**SDD**_ 硬盤比普通硬盤性能更好。通常數據存儲在本地，避免使用 **_NFS & SMB_** 等遠程文件系統。還要小心虛擬化存儲，像亞馬遜的 _彈性塊存儲_（_Elastic Block Storage_）。**Elasticsearch** 在虛擬存儲上也有比較好的性能，具有搜索快，安裝便捷的特性；然而相對于本地專用存儲，他就要慢的多了。如果你在 _**EBS**_上使用 _index ，_一定要使用 _IOPS_ 否則操作會很快掛掉。通過配置RAID 0陣列，將您的索引分離到多個** _SSD_ **。但是，這將增加失敗的風險，因為任何一個 _**SSD**_ 的失敗都將破壞這個索引。然而，權衡之后做出如下策略：優化單個分片以實現最佳性能，然后在不同節點之間添加副本，以便任何節點故障都有冗余。您還可以使用快照和還原來備份索引進行進一步的保險。 ## 索引緩沖區大小如果您的節點僅進行大量索引，請確保 **_indices.memory.index_buffer_size_** 足夠大，以至于每個 _shard（分片）_最多可以為 512 MB 索引緩沖區進行大量索引（超出索引性能通常不會改善）。_Elasticsearch_ 采用該設置（java堆的百分比或絕對的字節大小），并將其用作所有活動 _shard（分片）_的共享緩沖區。非常活躍的 _shard（分片）_自然會使用這個緩沖區，而不是執行少量索引的 _shard（分片）_。? 通常這個默認值為10％，已經非常富余了：例如，如果給予JVM 10GB內存，則它將向索引緩沖區提供1GB，這足夠兩個大量索引的 _shard（分片）_。 ## 額外優化調整磁盤使用的策略，也能提高索引的速率。