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 原理
作者：楊松柏
轉載請註明出處，本文鏈接：https://www.uj5u.com/shujuku/523991.html
標籤：其他