Elasticsearch最佳實踐之分片使用優化

本文由雲+社區發表

做者：老生薑

1、遇到的問題

  與大多數分佈式系統同樣，Elasticsearch按照必定的Hash規則把用戶數據切分紅多個分片，而後打散到不一樣機器進行存儲，從而實現大規模數據的分佈式存儲。

cluster.png

  然而在一些複雜的應用場景中使用Elasticsearch，常常會遇到分片過多引起的一系列問題。起初咱們在支撐內部某業務時，單集羣內有約1000個子業務，大部分子業務保留31天的數據。若是每一個子業務按天滾動創建Index，每一個Index 5個分片、一主兩從共三副本的狀況下，集羣內部會有多達45w~個分片。在集羣內分片過多時，常常遇到下面這些問題：

  1. 建立分片慢：Elasticsearch建立分片的速度會隨着集羣內分片數的增長而變慢。以ES 5.5.2版本、3節點集羣爲例，在默認配置下，當集羣分片數超過1w時，建立index的耗時通常在幾十秒甚至以上。   2. 集羣易崩潰：在凌晨觸發Elasticsearch自動建立Index時，因爲建立速度太慢，容易致使大量寫入請求堆積在內存，從而壓垮集羣。   3. 寫入拒絕：分片過多的場景中，若是不能及時掌控業務變化，可能常常遇到單分片記錄超限、寫入拒絕等問題。

2、解決過程

1. 拆分集羣 對於存在明顯分界線的業務，能夠按照業務、地域使用不一樣集羣，這種拆分集羣的思路是很是靠譜的。Elasticsearch官方建議使用小而美的集羣，避免巨無霸式的集羣，咱們在實際使用過程當中對這一點也深有體會。但對於咱們的場景，已經按照地域拆分了集羣，且同一地域的子業務間分界線不明顯，拆分過多的集羣維護成本較高。
2. 調整滾動週期 根據保留時長調整index滾動週期是最簡單有效的思路。例如保留3天的數據按天滾動，保留31天的數據按周滾動，保留一年的數據按月滾動。合理的滾動週期，能夠在存儲成本增長不大的狀況下，大幅下降分片數量。 對於咱們的場景，大部分數據保留31天，在按周滾動的狀況下，集羣的總分片數能夠降低到6.5w~個。
3. 合理設置分片數和副本數 集羣內部除個別子業務壓力較高外，大部分業務壓力較小，合理設置單Index的分片數效果也不錯。咱們的經驗是單個分片的大小在10GB~30GB之間比較合適，對於壓力很是小的業務能夠直接分配1個分片。其餘用戶可結合具體場景考慮，同時注意單分片的記錄條數不要超過上限2,147,483,519。 在平衡咱們的業務場景對數據可靠性的要求 及 不一樣副本數對存儲成本的開銷 兩個因素以後，咱們選擇使用一主一從的副本策略。 目前咱們集羣單Index的平均分配數爲3，集羣的總分片數降低到3w~個。
4. 分片分配流程優化 默認狀況下，ES在分配分片時會考慮分片relocation對磁盤空間的影響。在分片數較少時，這個優化處理的反作用不明顯。但隨着單機分片數量的上升，這個優化處理涉及的多層循環嵌套過程耗時愈發明顯。可經過cluster.routing.allocation.disk.include_relocations: false關閉此功能，這對磁盤均衡程度影響不明顯。
5. 預建立Index 對於單集羣3w分片的場景，集中在每週某天0點建立Index，對集羣的壓力仍是較大，且存儲空間存在波動。考慮到集羣的持續擴展能力和可靠性，咱們採用預建立方式提早建立分片，並把按Index的建立時間均勻打散到每週的每一天。
6. 持續調整分片數 對於集羣分片的調整，一般不是一蹴而就的。隨着業務的發展，不斷新增的子業務 或 原有子業務規模發生突變，都須要持續調整分片數量。 默認狀況下，新增的子業務會有默認的分片數量，若是不足，會在測試階段及上線初期及時發現。隨着業務發展，系統會考慮Index近期的數據量、寫入速度、集羣規模等因素，動態調整分片數量。

3、後續

  目前，Elasticsearch的分片均衡策略尚有瑕疵，例如：1. 機器的空間利用不是很是均衡，對於此類場景，用戶可暫時經過調整機器空間的高低水位線配置觸發數據均衡；2. 當集羣擴容新節點時，Elasticsearch會把大量新建分片分配到新機器，致使新機器壓力太高，目前用戶可臨時經過index.routing.allocation.total_shards_per_node配置進行限制。

  這是咱們後續在分片使用方面的優化工做，經過直接優化分片均衡策略，更優雅的解決上述問題。若是你們有分片使用方面的問題 或 經驗，歡迎一塊兒交流討論！

此文已由騰訊雲+社區在各渠道發佈

獲取更多新鮮技術乾貨，能夠關注咱們騰訊雲技術社區-雲加社區官方號及知乎機構號