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 原理
作者：楊松柏