JuiceFS 元數據引擎選型指南

文件系統是我們常見的存儲形式,內部主要由數據和元數據兩部分組成 。其中數據是文件的具體內容,通常會直接展現給用戶;而元數據是描述數據的數據 , 用來記錄文件屬性、目錄結構、數據存儲位置等 。一般來說,元數據有非常鮮明的特點,即占用空間較?。夢史淺F搗?。
當今的分布式文件系統中,有的(如 S3FS)會將元數據和數據統一管理,以簡化系統設計,不過這樣的弊端是某些元數據操作會讓用戶感受到明顯的卡頓,如 ls 大目錄 , 重命名大文件等 。更多的文件系統會選擇將這兩者分開管理,并根據元數據的特點進行針對性優化 。JuiceFS 采用的就是這種設計,其架構圖如下:

JuiceFS 元數據引擎選型指南

文章插圖
其中,元數據引擎需要是能夠支持事務操作的數據庫,而數據引擎一般是用對象存儲 。目前為止 , JuiceFS 已經支持 10 種以上元數據引擎和 30 種以上數據引擎 。
用戶在使用 JuiceFS 時可以自由地選擇成熟組件來充當這兩個引擎,以應對豐富多變的企業環境和數據存儲需求 。然而對于新用戶來說,當面對更多選擇時,也帶來了一個問題:在我的場景中究竟選擇哪一款數據庫作為元數據引擎比較合適?這篇文章將從產品設計角度,為大家介紹 JuiceFS 可使用的元數據引擎類型,以及他們的優劣勢 。
01-JuiceFS 元數據引擎類型JuiceFS 現在支持的元數據引擎總共有有三大類 。
第一個是 Redis 。Redis 是 JuiceFS 開源后最早支持的元數據引擎 。首先 Redis 速度夠快,這是元數據引擎需要具備的重要能力之一;其次,Redis 受眾面廣,大部分用戶對 Redis 都有實踐經驗 。JuiceFS 對兼容 Redis 協議的數據庫也都實現了支持,比如 KeyDB、Amazon MemoryDB 等 。
然而,Redis 的可靠性和擴展性容易受限,在一些數據安全性要求較高或規模較大的場景中表現乏善可陳,因此我們又開發支持了另外兩類引擎 。
第二個是 SQL 類 。如 MySQL、MariaDB、PostgreSQL 等,它們的特點是流行度較高,且通常具有不錯的可靠性與擴展性 。另外,還支持了嵌入式數據庫 SQLite 。
最后一個是 TKV(Transactional Key-Value Database)類 。它們的原生接口比較簡單,因此在 JuiceFS 中的定制性更好,相較于 SQL 類一般也能有更高的性能 。目前這一類支持的有 TiKV、etcd 和嵌入式的 BadgerDB 等,對 FoundationDB 的支持也在緊鑼密鼓地開發中 。
以上是根據 JuiceFS 在對接數據庫時的協議接口進行的分類 。每個大類里面有各種不同的數據庫,每種數據庫又有其自身的特點,以下根據這些特點對用戶常用的幾個選項進行比較 。
元數據引擎比較RedisMySQL/PostgreSQLTiKVetcdSQLite/BadgerDB性能高低中低中擴展性低中高低低可靠性低高高高中可用性中高高高低流行度高高中高中如上文中提到的 , Redis 的最大優勢是性能高,因為它是全內存的數據庫 。其他幾方面它就表現平平 。
從擴展性上說,通常單機 Redis 可以支持 1 億文件左右,超過 1 億時,Redis 單進程的內存使用量會比較大,管理性能上也會有所下降 。開源版 Redis 支持以集群模式來擴展其可管理的數據總量,但由于集群模式下 Redis 并不支持分布式事務 , 因此作為 JuiceFS 元數據引擎時,每個 JuiceFS volume 能用的 Redis 進程還是只有一個,單 volume 的擴展性相較于單機 Redis 并沒有太大提升 。
從可靠性來看,Redis 默認每秒將數據刷盤,在異常時可能導致小部分數據丟失 。通過將配置 appendfsync 改為 always,可以讓 Redis 在每個寫請求后都刷盤,這樣數據可靠性能提高,但是性能卻會下降 。
從可用性來說,部署 Redis 哨兵監控節點和備用節點 , 可以在主 Redis 節點掛掉后選擇一個備份節點來重新提供服務,一定程度上提高可用性 。然而,Redis 本身并不支持分布式的一致性協議,其備用節點采用的是異步備份 , 所以雖然新的節點起來了,但是中間可能會有數據差,導致新起來的數據并不是那么的完整 。
MySQL 和 PostgreSQL 的整體表現比較類似 。它們都是經過大量用戶多年時間驗證過的數據庫產品,可靠性和可用性都不錯 , 流行度也很高 。只是相較于其余元數據引擎,它們的性能一般 。
【JuiceFS 元數據引擎選型指南】TiKV 原本是 PingCAP TiDB 的底層存儲,現在已經分離出來,成為一個獨立的 KV 數據庫組件 。從我們的測試結果來看,它用來作為 JuiceFS 的元數據引擎是一個非常出色的選擇 。其本身就有不弱于 MySQL 的數據可靠性和服務可用性,而且在性能與擴展性上表現更好 。只是在流行度上,它和 MySQL 還有差距 。從我們與用戶交流來看 , 如果他們已經是 TiKV 或 TiDB 的用戶,那最后通常都會偏向使用 TiKV 來做 JuiceFS 的元數據引擎 。但如果他們之前對 TiKV 并不熟悉,那要再接受這樣一個新的組件就會慎重許多 。

推薦閱讀