0、引言

本文翻譯自Elasticsearch20170918熱乎的官方部落格，原作者：Christian Dahlqvist。 在構建Elasticsearch叢集的初期如果叢集分片設定不合理，可能在專案的中後期就會出現效能問題。

Elasticsearch是一個非常通用的平臺，支援各種各樣的用例，並且為資料組織和複製策略提供了巨大靈活性。這種靈活性使得作為ELK新手的你將資料組織成索引和分片變得困難。雖然不一定會在首次啟動時出現問題，但由於資料量隨時間的推移，可能會導致效能問題。叢集所擁有的資料越多，糾正問題就越困難，甚至有時可能需要重新索引大量資料。

當我們遇到遭遇效能問題的使用者時，可以追溯到關於資料索引的資料和群集數量的問題並不罕見。 對於涉及multi-tenancy或使用基於時間的索引的使用者尤其如此。 在與使用者討論這個問題時（會議、論壇形式），引申出的一些最常見的問題是：

1）“我應該有多少個分片？”
2）“我的分片應該有多大”？

這篇部落格文章旨在幫助您回答這些問題，併為使用基於時間的索引的使用案例（ 日誌記錄或安全分析 ）提供實用的指導。

1、什麼是分片？

在開始之前，讓我們約定文章中用到的一些概念和術語。
Elasticsearch中的資料組織成索引。每一個索引由一個或多個分片組成。每個分片是Luncene索引的一個例項，你可以把例項理解成自管理的搜尋引擎，用於在Elasticsearch叢集中對一部分資料進行索引和處理查詢。

【重新整理】當資料寫入分片時，它會定期地釋出到磁碟上的新的不可變的Lucene段中，此時它可用於查詢。——這被稱為重新整理。更詳細的解讀請參考：

【合併】隨著分段數（segment）的增長，這些segment被定期地整合到較大的segments。 這個過程被稱為合併（merging）。

由於所有段都是不可變的， 因為新的合併段需要建立，舊的分段將被刪除 ，這意味著所使用的磁碟空間通常在索引時會波動。 合併可能資源相當密集，特別是在磁碟I/O方面。

分片是Elasticsearch在叢集周圍分發資料的單位。 Elasticsearch在重新平衡資料時 （例如 發生故障後） 移動分片的速度 取決於分片的大小和數量以及網路和磁碟效能。

提示：避免有非常大的分片，因為大的分片可能會對叢集從故障中恢復的能力產生負面影響。 對於多大的分片沒有固定的限制，但是分片大小為50GB通常被界定為適用於各種用例的限制

2、索引有效期（ retention period ）

由於段是不可變的，更新文件需要Elasticsearch首先查詢現有文件，然後將其標記為已刪除，並新增更新的版本。刪除文件還需要找到文件並將其標記為已刪除。因此，刪除的文件將繼續佔據磁碟空間和一些系統資源，直到它們被合併，這將消耗大量的系統資源。

Elasticsearch允許從檔案系統直接刪除完整索引，而不必明確地必須單獨刪除所有記錄。這是迄今為止從Elasticsearch刪除資料的最有效的方式。

提示：儘可能使用基於時間的索引來管理資料。根據保留期（retention period，可以理解成有效期）將資料分組。基於時間的索引還可以輕鬆地隨時間改變主分片和副本分片的數量（以為要生成的下一個索引進行更改）。這簡化了適應不斷變化的資料量和需求。

3、索引和分片不是空閒的？

【叢集狀態】對於每個Elasticsearch索引，其對映和狀態的資訊都儲存在叢集狀態。 這些叢集狀態資訊儲存在記憶體中以便快速訪問。 因此，如果在叢集中擁有大量索引，可能導致大的叢集狀態（特別是如果對映較大）。 所有更新叢集狀態操作為了在叢集中保證一致性，需要通過單個執行緒完成，因此更新速度將變慢。

提示：為了減少索引數量並避免大的乃至非常龐大的對映，請考慮將相同索引結構的資料儲存在相同的索引中，而不是基於資料的來源將資料分割成獨立的索引。 在每個索引的索引數量和對映大小之間找到一個很好的平衡很重要。**

每個分片都有資料需要儲存在記憶體中並使用堆空間。 這包括在分片級別儲存資訊的資料結構，也包括在段級別的資料結構，以便定義資料駐留在磁碟上的位置。 這些資料結構的大小不是固定的，並且將根據用例而有所不同。

然而，段相關開銷的一個重要特徵是它與分段的大小不成正比。 這意味著與較小的段相比，較大的段的每個資料量具有較少的開銷，且這種差異很大。

【堆記憶體的重要性】為了能夠每個節點儲存儘可能多的資料，重要的是儘可能多地管理堆記憶體使用量並減少其開銷。 節點擁有的堆空間越多，它可以處理的資料和分片越多。

因此，索引和分片從叢集的角度看待不是空閒的，因為每個索引和分片都有一定程度的資源開銷。

提示1：小分片會導致小分段(segment)，從而增加開銷。目的是保持平均分片大小在幾GB和幾十GB之間。對於具有基於時間的資料的用例，通常看到大小在20GB和40GB之間的分片。

提示2：由於每個分片的開銷取決於分段數和大小，通過強制操作迫使較小的段合併成較大的段可以減少開銷並提高查詢效能。一旦沒有更多的資料被寫入索引，這應該是理想的。請注意，這是一個消耗資源的（昂貴的）操作，較為理想的處理時段應該在非高峰時段執行。

提示3：您可以在叢集節點上儲存的分片數量與您可用的堆記憶體大小成正比，但這在Elasticsearch中沒有的固定限制。 一個很好的經驗法則是：確保每個節點的分片數量保持在低於每1GB堆記憶體對應叢集的分片在20-25之間。 因此，具有30GB堆記憶體的節點最多可以有600-750個分片，但是進一步低於此限制，您可以保持更好。 這通常會幫助群體保持處於健康狀態。

4、分片的大小如何影響效能？

在Elasticsearch中，每個查詢在每個分片的單個執行緒中執行。然而，可以並行處理多個分片，並可以在相同分片上執行多個查詢和聚合。

【小分片的利弊】這意味著，在不涉及快取記憶體時，最小查詢延遲將取決於資料、查詢的型別、分片的大小。查詢大量小分片將使得每個分片的處理速度更快，但是隨著更多的任務需要按順序排隊和處理，它不一定要比查詢較小數量的更大的分片更快。如果有多個併發查詢，則有很多小碎片也會降低查詢吞吐量。

提示：從查詢效能角度確定最大分片大小的最佳方法是使用逼真的資料和查詢進行基準測試（真實資料而非模擬資料）。 始終使用查詢和索引負載進行基準測試，代表節點在生產中需要處理的內容，因為單個查詢的優化可能會產生誤導性的結果。

5、如何管理分片大小？

當使用基於時間的索引時，每個索引傳統上都與固定的時間段相關聯。 每日索引非常普遍，經常用於持有時間區間短或每日量大的資料。 這些允許資料期限期間以良好的粒度進行管理，並且可以方便地對每天更換調整volumes。

時間週期長的資料，特別是如果每日不儲存每天的索引資料，則通常會使用每週或每月的儲存的碎片大小的增加。 這減少了隨著時間的流逝需要儲存在群集中的索引和碎片數量大小（直譯有點費勁此處）。

提示：如果使用固定期限的時間索引資料，可以根據時間週期和預期資料量調整所涵蓋的時間範圍，以達到目標分片大小。

【均勻更新&快速變化的索引資料對比】具有固定時間間隔的基於時間的索引在資料量合理預測並且變化緩慢的情況下工作良好。 如果索引率可以快速變化，則很難保持均勻的目標分片大小。

為了能夠更好地處理這種情況，推出了Rollover和S**hrink API**。 這些增加了如何管理索引和分片的靈活性，尤其適用於基於時間的索引。

此處省略了 Rollover和Shrink API的介紹。（建議查詢官網補齊概念再深入）

6、結論

這篇部落格文章提供了有關如何在Elasticsearch中最好地管理資料的提示和實用指南。 如果您有興趣瞭解更多，推薦閱讀Google搜尋 “Elasticsearch: the definitive guide” （有點舊，值得閱讀）。

然而，關於如何最好地在索引和分片上分發資料的許多決策將取決於用例細節，有時可能難以確定如何最佳地應用可用的建議。

文章提及的幾個核心建議清單如下，以回答文章開頭的提問。

1） “我應該有多少個分片？”
答： 每個節點的分片數量保持在低於每1GB堆記憶體對應叢集的分片在20-25之間。
2） “我的分片應該有多大”？
答：分片大小為50GB通常被界定為適用於各種用例的限制。

還是讀起來有點拗口，一些概念還是不夠深入，不能很好的深入淺出的講解。
待我實踐中更新吧。更多細節，歡迎討論！

——————————————————————————————————
更多ES相關實戰乾貨經驗分享，請掃描下方【銘毅天下】微信公眾號二維碼關注。
（每週至少更新一篇！）

和你一起，死磕Elasticsearch！
——————————————————————————————————

2017年09月24日 22:34 於家中床前