測試的時候 JuiceFS1.0 還沒有發布，測試的過程中確實發現了問題，在實時寫的過程中會出現了數據損壞的情況，跟社區溝通后可以通過修改緩存的大小來避免：

–attr-cache=0.1 屬性緩存時長，單位秒 (默認值: 1)

–entry-cache=0.1 文件項緩存時長，單位秒 (默認值: 1)

–dir-entry-cache=0.1 目錄項緩存時長，單位秒 (默認值: 1)

這三個參數的緩存默認是 1，把時長改成 0.1，它確實解決了索引損壞的問題，但是會帶來一些新的問題，因為元數據的緩存和數據緩存的時間變短，會導致在執行系統命令的時候，比如 curl 一個系統命令，查看索引數量或者集群狀態，正常的情況下，調用可能在秒級，而這種變化可能導致需要數 10 秒才能夠完成。

第二個問題就是寫入的 QPS 有明顯下降。我們可以看到監控圖中 Write QPS 非常不穩定，這并不代表 ES 真實的 QPS，因為監控圖中的 QPS 是通過兩次得到的 documents 數量來做差得到的，由于舊版 JuiceFS 存在一些內核緩存問題，導致 ES 讀到了一些舊數據。我們把該問題反饋給了社區， JuiceFS 1.0 正式發布后問題得到解決。

我們就進行了新一輪的測試，新一輪的測試確定了 hot 節點 3 臺，8C16G 500G SSD， warm 節點 2 臺，4C16G 200G SSD，測試時長 1 周，每天寫入數據量 1TB (1 副本)，1 天后轉到 warm 節點 。沒有再出現索引數據損壞情況，通過這次壓測沒有再出現之前遇到的問題，這就給了我們信心，接下來我們把整個的 ES 逐漸的往這方面來做遷移。

JuiceFS 數據存儲和對象存儲的差異
JuiceFS 有自己的元數據，所以在對象存儲上和 JuiceFS 當中看到的目錄結構是不一樣的。

JuiceFS 分為三層結構，chunk、slice、block，因此我們在對象存儲上面看到的是 JuiceFS 對文件做拆分之后的數據塊。但是所有的數據是通過 ES 來管理，所以這一點用戶不需要關注，只需要通過 ES 來執行所有的文件系統操作即可。JuiceFS 會恰當管理對象存儲中的數據塊。

經過這一系列的測試后， 金山云將 JuiceFS 應用在日志服務（ Klog）中，為企業用戶提供一站式日志類數據服務，實現了云上的數據可以不出云，直接就完成數據采集，存儲分析以及告警的一站式服務；云下的數據提供了 SDK 客戶端，通過采集工具來實現數據上云的整個整條鏈路，最后可以把數據投遞到 KS3 和 KMR，來實現數據的加工計算。

03 Elasticsearch 冷熱數據管理
ES 有幾個常用概念： Node Role 、Index Lifecycle Management 、 Data Stream。

Node Role，節點角色。每一個 ES 節點會分配不同的角色，比如 master、data、ingest。重點介紹一下 data 節點，老版本是分為三種，就是 hot、warm、cold 節點，在最新的版本里面增加了 freeze ，冷凍節點。

Index Lifecycle Management（ILM）我們分為了 4 個階段：

hot: 索引正在被頻繁更新和查詢。
warm: 索引不再被更新，但查詢量一般。
cold: 索引不再被更新，并且很少被查詢。這些信息仍然需要可搜索，但如果查詢速度較慢也沒關系。
delete: 索引不再需要，可以安全地刪除。

ES 官方提供了一個生命周期的管理工具，我們可以基于索引的大小，docs 數量的大小以及時間策略，把一個大的索引拆分成成多個小索引。一個大索引從管理運維查詢，它的開銷的代價是非常大的。生命周期管理功能方便我們更靈活地管理索引。

Data Stream 是在 7.9 版本提出推出了一個新功能，它是基于索引生命周期管理來實現了一個數據流寫入，可以很方便地處理時間序列數據。

在查詢多個索引時，通常是把這些索引合并在一起來查詢，我們可以使用 Data Stream，他就像一個別名一樣，可以自行路由到不同的索引里面。Data Stream 對時序數據的存儲管理和查詢來說更友好，這個是來對 ES 的冷熱管理上面是來更近了一步，方便整個的運維管理。

總結

以上是生活随笔為你收集整理的通过生命周期管理来做热数据到冷数据的迁移的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。