Elasticsearch在db_ranking 的排名又（雙叒叕）上升了一位,如圖1-1所示;由此可見es在儲存領域已經蔚然成風且佔有非常重要的地位。

隨著Elasticsearch越來越受歡迎，企業花費在ES建設上的成本自然也不少。那如何減少ES的成本呢？今天我們就特地來聊聊ES降本增效的常見方法：

• 彈性伸縮
• 分級儲存
• 其他：（1）資料壓縮（2）off heap
  

圖 1-1 Elasticsearch db_ranking

1 彈性伸縮

所謂彈性伸縮翻譯成大白話就是隨時快速瘦身與增肥，並且是頭痛醫頭，按需動態調整資源。當計算能力不足的時候我們可以快速擴充出計算資源；當儲存資源不足時，能夠快速擴容磁碟。

1-1 計算儲存分離

ES使用計算儲存分離架構之後，解決了資源預留而造成資源浪費的問題。在早期大家認為的計算儲存分離的實現方式為：使用雲盤代替本地盤，這種實現方式可以提高資料的可靠性、可以快速彈擴磁碟資源和計算資源，但是es自身彈性需求是無法解決，即秒級shard搬遷和replica擴容。

那麼如何解決es自身的彈性呢？本文該部分將給出答案。

共享儲存版ES

本文該部分將介紹我們京東雲-中介軟體搜尋團隊，研發的共享儲存版本ES；計算儲存分離架構如圖1-2所示

圖 1-2 計算儲存分離架構(共享)

如圖1-2所示，我們只儲存一份資料，primary shard負責讀寫，replica只負責讀；當我們需要擴容replica的時候無需進行資料搬遷,直接跳過原生es的peer recover兩階段，秒級完成replica的彈擴。

當主分片發生relocating時,可以直接跳過原生es的peer recover第一階段(該階段最為耗時)，同時也不需要原生es的第二階段傳送translog。

共享版本的計算儲存分離ES，相對於原生的ES和普通版本的計算儲存分離，具有如下突出的優勢：

• 資料只儲存一份，儲存成本倍數級降低
• 儲存容量按需自動擴充，幾乎無空間浪費
• 按實際用量計費，無需容量規劃

效能測試

• 資料集為esrally提供的http_logs
• 共享版ES7.10.2: 3個data節點(16C64GB)
• 原生ES7.10.2: 3個data節點(16C64GB)

表 1-1 副本效能測試對比

我們的初步效能測試結果如表1-1所示；副本數越多，共享版本的es越具有優勢;

從表1-1所示我們可以看出效能似乎提升的不是特別理想，目前我們正從兩個方面進行最佳化提升：

• 底層依賴的雲海儲存，目前正在有計劃地進行著效能提升
• 原始碼側，我們也在正在最佳化ing

在研發es計算儲存分離的過程中，我們攻克了很多的問題,後續將輸出更加詳細的文章進行介紹，比如：主寫副只讀的具體實現，replica的訪問近實時問題，ES的主分片切換髒寫問題等等。

1-2 外部構建Segment

對於有大量寫入的場景，通常不會持續的高流量寫入，而只有1-2個小時寫入流量洪峰；在寫入過程中最耗費時間的過程並不是寫磁碟而是構建segment,既然構建segment如此耗時，那麼我們是否可以將該部分功能單獨出來，形成一個可快速擴充套件的資源（避免去直接改動es原始碼而引入其他問題）。

目前業界已經有比較好的案例外部構建Segment，相對於共享儲存版的es實現起來更簡單；它的核心解決方案使用了spark或者map reduce這種批處理引擎進行批次計算處理，然後將構建好的segment搬運到對應的索引shard即可。

外部構建segment的功能也在我們的規劃中。

2 分級儲存

ES實現降本增效的另外一個方向：分級儲存，該解決方案主要是針對資料量大查詢少且對查詢耗時不太敏感的業務。分級儲存，比較成熟的解決方案有es冷熱架構和可搜尋快照。

2-1 冷熱架構

冷熱架構適用場景：時序型資料或者同一叢集中同時存在這兩個索引（一個熱資料，另外一個冷資料）

es冷熱架構架構，該功能已經在京東雲上線有一段時間了，歡迎大家根據自己的業務形態進行試用，冷資料節點開啟如圖2-1所示

圖 2-1 冷資料節點開啟

建議如果索引表是按天/小時，這種週期儲存的資料，且資料查詢具有冷熱性，建議開啟冷節點；開啟冷節點後你可能會獲得如下的收益：

• 開啟冷節點後可以降低你的儲存成本，因為存放冷節點的索引我們可以選擇減少副本數、冷節點的儲存介質更便宜
• 叢集可以存放更多的資料
• 冷資料forcemerge,提升冷資料的查詢效能
• 冷資料從熱節點遷移走之後，減少熱節點的資源佔用，從而使熱查詢更快

冷熱架構的核心技術為
shard-allocation-filtering;
冷熱架構實現原理：
es的hot節點增加如下配置

node.attr.box_type: hot

es的warm節點增加如下配置

node.attr.box_type: warm

熱資料索引setting增加如下配置，即可限制shard分配在hot節點

"index.routing.allocation.require.box_type": "hot"

當資料查詢減弱，我們透過如下配置，即可使資料由hot節點遷移到warm節點

"index.routing.allocation.require.box_type": "warm"

2-2 可搜尋快照

可搜尋快照是在冷熱架構的基礎上更進一步的分級儲存，在之前我們將資料快照之後是無法對快照的資料進行搜尋，如果要對快照的資料進行搜尋，則需將快照資料先restore（restore的過程可能會比較長）之後才能被搜尋。

在引入可搜尋快照之後，我們可以直接搜尋快照中的資料，大大降低了沒必要的資源使用.

3 其他

3-1 資料壓縮

除了從資源的角度進行降低儲存成本之外，基於資料自身的特性，使用優秀的壓縮演算法也是一種必不可少的搜尋；針對時序資料facebook開源了一個非常優秀的壓縮演算法zstd，目前已經在業界被大量使用。

表 3-1 三種壓縮演算法的對比測試結果

目前在lucene的程式碼庫中也有開源愛好者提交了custom codec providing Zstandard compression/decompression （zstd pr）

3-2 off heap

es單個節點儲存資料量受到jvm堆記憶體的限制，為了使單個節點能夠儲存更多的資料，因此我們需要減少堆記憶體中的資料。

ES 堆中常駐記憶體中佔據比重最大是 FST，即 tip(terms index) 檔案佔據的空間，1TB 索引大約佔用2GB 或者更多的記憶體，因此為了節點穩定執行，業界通常認為一個節點 open 的索引不超過5TB。現在，從 ES 7.3版本開始，將 tip 檔案修改為透過mmap的方式載入，這使 FST佔據的記憶體從堆內轉移到了堆外(即off Heap技術 )由作業系統的 pagecache 管理[6]。

使用esrally官方資料集geonames寫入索引1TB,使用 _cat/segments API 檢視 segments.memory記憶體佔用量，對比 offheap 後的記憶體佔用效果,如表3-2所示;JVM 記憶體佔用量降低了78%左右

表 3-2 segments.memory記憶體佔用量

4 參考

[1] Indexing Service
[2] ES-Fastloader
[3] 大規模測試新的 Elasticsearch 冷層可搜尋快照
[4] Introducing Elasticsearch searchable snapshots
[5] 7.7 版本中的新改進：顯著降低 Elasticsearch 堆記憶體使用量
[6] Elasticsearch 7.3 的 offheap 原理

作者：楊松柏