京東云開發者|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 分級存儲【京東云開發者|ElasticSearch降本增效常見的方法】ES實現降本增效的另外一個方向:分級存儲 , 該解決方案主要是針對數據量大查詢少且對查詢耗時不太敏感的業務 。分級存儲,比較成熟的解決方案有es冷熱架構和可搜索快照 。
2-1 冷熱架構冷熱架構適用場景:時序型數據或者同一集群中同時存在這兩個索引(一個熱數據,另外一個冷數據)
es冷熱架構架構 , 該功能已經在京東云上線有一段時間了,歡迎大家根據自己的業務形態進行試用,冷數據節點開啟如圖2-1所示

推薦閱讀