京東雲開發者｜ElasticSearch降本增效常見的方法
- 2022 年 10 月 31 日
- 筆記
- elasticsearch, 京東雲技術, 技術分享, 數據庫
Elasticsearch在db_ranking 的排名又（雙叒叕）上升了一位,如圖1-1所示;由此可見es在存儲領域已經蔚然成風且佔有非常重要的地位。
隨着Elasticsearch越來越受歡迎，企業花費在ES建設上的成本自然也不少。那如何減少ES的成本呢？今天我們就特地來聊聊ES降本增效的常見方法：
- 彈性伸縮
- 分級存儲
- 其他：（1）數據壓縮（2）off heap
圖 1-1 Elasticsearch db_ranking
1 彈性伸縮
所謂彈性伸縮翻譯成大白話就是隨時快速瘦身與增肥，並且是頭痛醫頭，按需動態調整資源。當計算能力不足的時候我們可以快速擴充出計算資源，業屆比較有代表性的兩個ES相關產品阿里雲Indexing Service 和 滴滴的ES-Fastloader；
當存儲資源不足時，能夠快速擴容磁盤，業屆比較代表性es產品:阿里雲的ES日誌增強版。
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的主分片切換臟寫問題等等。目前共享版本的ES正在內部進行公測，歡迎在雲搜平台進行試用。
1-2 外部構建Segment
對於有大量寫入的場景，通常不會持續的高流量寫入，而只有1-2個小時寫入流量洪峰；在寫入過程中最耗費時間的過程並不是寫磁盤而是構建segment,既然構建segment如此耗時，那麼我們是否可以將該部分功能單獨出來，形成一個可快速擴展的資源（避免去直接改動es源碼而引入其他問題）。
目前業界已經有比較好的案例如阿里雲的Indexing Service 和滴滴開源的 ES-Fastloader 外部構建Segment，相對於共享存儲版的es實現起來更簡單；它的核心解決方案使用了spark或者map reduce這種批處理引擎進行批量計算處理，然後將構建好的segment搬運到對應的索引shard即可。它的詳細實現,我這裡就不做搬運工了，大家感興趣可以參考滴滴發佈的文章《滴滴離線索引快速構建FastIndex架構實踐》
外部構建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，
目前已經在業界被大量使用，國內的兩大雲友商已經在es進行了實現，騰訊雲針對zstd的測試結果如表3-1所示;阿里雲在TimeStream功能中使用了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 原理
作者：楊松柏
