1. 首頁 > 生活百科 > >

京東云開發者｜ElasticSearch降本增效常見的方法( 二 )

生活百科




圖 2-1 冷數據節點開啟
建議如果索引表是按天/小時，這種周期存儲的數據，且數據查詢具有冷熱性，建議開啟冷節點；開啟冷節點后你可能會獲得如下的收益：

  • 開啟冷節點后可以降低你的存儲成本，因為存放冷節點的索引我們可以選擇減少副本數、冷節點的存儲介質更便宜
  • 集群可以存放更多的數據
  • 冷數據forcemerge,提升冷數據的查詢性能
  • 冷數據從熱節點遷移走之后，減少熱節點的資源占用，從而使熱查詢更快
冷熱架構的核心技術為shard-allocation-filtering;冷熱架構實現原理：es的hot節點增加如下配置
node.attr.box_type: hotes的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 heapes單個節點存儲數據量受到jvm堆內存的限制 ， 為了使單個節點能夠存儲更多的數據，因此我們需要減少堆內存中的數據 。
ES 堆中常駐內存中占據比重最大是 FST ， 即 tip(terms index) 文件占據的空間，1TB 索引大約占用2GB 或者更多的內存 ， 因此為了節點穩定運行，業界通常認為一個節點 open 的索引不超過5TB ?，F在，從 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 原理
作者：楊松柏

推薦閱讀