最近，留意到 MinIO 官方博客的一篇題為“在對象存儲上實現(xiàn) POSIX 訪問接口是壞主意[1]”的文章，作者以 S3FS-FUSE 為例分享了通過 POSIX 方式訪問 MinIO 中的數(shù)據(jù)時碰到了性能方面的困難，性能遠不如直接訪問 MinIO。在對結(jié)果進行分析時，作者認(rèn)為是 POSIX 本身存在的缺陷導(dǎo)致的性能問題。這個結(jié)論與我們既有經(jīng)驗有一定出入。

我們知道 POSIX 是一個有用而且廣泛應(yīng)用的標(biāo)準(zhǔn)，遵循它而開發(fā)的程序可以保證不同操作系統(tǒng)之間的兼容性和可移植性。各行各業(yè)中常用的業(yè)務(wù)系統(tǒng)和應(yīng)用程序，大多遵循 POSIX 標(biāo)準(zhǔn)。

隨著云計算、大數(shù)據(jù)、人工智能等技術(shù)的發(fā)展和數(shù)據(jù)存儲量的攀升，本地化應(yīng)用也逐漸產(chǎn)生對對象存儲等彈性存儲的需求，MinIO 等對象存儲雖然提供了各種語言的 SDK，但許多傳統(tǒng)應(yīng)用很難甚至無法修改代碼去適配對象存儲的訪問接口，這促使很多存儲產(chǎn)品在對象存儲的基礎(chǔ)上去實現(xiàn) POSIX 接口來滿足這樣的剛性需求。

業(yè)內(nèi)在對象存儲上實現(xiàn) POSIX 接口的產(chǎn)品有很多，比如 Ceph、JuiceFS、Weka 等，它們都有廣泛的用戶群和大量的成功案例，在性能方面也都有不錯的表現(xiàn)。

誠然，我們認(rèn)可 POSIX 存在較大的復(fù)雜性，需要付出很大的努力才能解決好相關(guān)的問題，但這些問題并不是無法解決。抱著尊重和求證的態(tài)度，我搭建了測試環(huán)境，采用相同的樣本和測試方法，進行了一番驗證。

測試項目

為了得到更為全面的測試結(jié)果，我將 JuiceFS 引入了對比。

JuiceFS 是開源的云原生分布式文件系統(tǒng)，它采用對象存儲作為數(shù)據(jù)存儲層，采用獨立的數(shù)據(jù)庫存儲元數(shù)據(jù)。提供了包括 POSIX API、S3 API、CSI Driver、HDFS API、WebDAV 在內(nèi)的多種訪問方式，具有獨特的數(shù)據(jù)分塊、緩存和并發(fā)讀寫機制。JuiceFS 是文件系統(tǒng)，與 s3fs-fuse 等只提供簡單的從對象存儲到 POSIX 協(xié)議轉(zhuǎn)換的工具有著本質(zhì)的不同。

通過將 JuiceFS 引入對比，可以更為客觀地求證以對象存儲為底層實現(xiàn) POSIX 等協(xié)議的利弊。

在本文中，我會對 MinIO、JuiceFS 和 s3fs-fuse 進行以下兩項測試：

1.10GB 大文件的寫入測試

2.Pandas 小文件覆蓋寫測試

在底層存儲方面，它們均使用部署在獨立服務(wù)器上的 MinIO 實例；在測試樣本方面，10GB 文件會采用那篇文章中使用的csv[2]文件。

本文所提及的環(huán)境、軟件、腳本、樣本數(shù)據(jù)等均提供完整的代碼和說明，確保讀者可以復(fù)現(xiàn)環(huán)境和測試結(jié)果。

服務(wù)器及測試環(huán)境準(zhǔn)備

兩臺配置相同的云服務(wù)器：

?System: Ubuntu 22.04 x64

?CPU: 8 cores

?RAM: 16GB

?SSD: 500GB

?Network: VPC

每臺服務(wù)器的信息如下：

Server A 的準(zhǔn)備工作

我在 Server A 上通過 Docker 部署了 MinIO，命令如下：

#創(chuàng)建并進入專用目錄
mkdirminio&&cdminio

#創(chuàng)建配置文件
mkdirconfig
touchconfig/minio

config/minio文件中寫入以下信息：

MINIO_ROOT_USER=admin
MINIO_ROOT_PASSWORD=abc123abc
MINIO_VOLUMES="/mnt/data"

2.創(chuàng)建 MinIO 容器：

sudodockerrun-d--nameminio
-p9000:9000
-p9090:9090
-v/mnt/minio-data:/mnt/data
-v./config/minio:/etc/config.env
-e"MINIO_CONFIG_ENV_FILE=/etc/config.env"
--restartunless-stopped
minio/minioserver--console-address":9090"

3.在 MinIO 的 Web Console 中預(yù)先創(chuàng)建三個 buckets：

Server B 的準(zhǔn)備工作

下載 10GB 測試樣本文件

curl-LOhttps://data.cityofnewyork.us/api/views/t29m-gskq/rows.csv?accessType=DOWNLOAD

2.安裝 mc 客戶端

mc 是 MinIO 項目開發(fā)的命令行文件管理器，可以在 Linux 命令行讀寫本地以及 S3 兼容的對象存儲。mc 的 cp 命令可以實時顯示數(shù)據(jù)拷貝的進度和速度，便于觀察各項測試。

注：為了保持測試的公平性，三種方案均采用 mc 進行寫測試。

#下載mc
wgethttps://dl.min.io/client/mc/release/linux-amd64/mc

#檢查版本
mc-v
mcversionRELEASE.2023-09-20T15-22-31Z(commit-id=38b8665e9e8649f98e6162bdb5163172e6ecc187)
Runtime:go1.21.1linux/amd64

# 安裝mc
sudoinstallmc/usr/bin

#為MinIO添加別名
mcaliassetmyhttp://172.16.254.18:9000adminabc123abc

3.安裝 s3fs-fuse

sudoaptinstalls3fs

#檢查版本
s3fs--version
AmazonSimpleStorageServiceFileSystemV1.93(commit:unknown)withOpenSSL

#設(shè)置對象存儲訪問密鑰
echoadmin:abc123abc>~/.passwd-s3fs

#修改密鑰文件權(quán)限
chmod600~/.passwd-s3fs

#創(chuàng)建掛載目錄
mkdirmnt-s3fs

#掛載對象存儲
s3fstest-s3fs://root/mnt-s3fs-ourl=http://172.16.254.18:9000-ouse_path_request_style

4.安裝 JuiceFS

這里使用官方提供的腳本安裝最新的 JuiceFS 社區(qū)版

#一鍵安裝腳本
curl-sSLhttps://d.juicefs.com/install|sh-

#檢查版本
juicefsversion
juicefsversion1.1.0+2023-09-04.08c4ae6

JuiceFS 是文件系統(tǒng)，需要先創(chuàng)建才能使用。除了對象存儲，還需要一個數(shù)據(jù)庫作為元數(shù)據(jù)引擎，支持多種數(shù)據(jù)庫，這里使用較常用的 Redis 作為元數(shù)據(jù)引擎。

注：我在這里將 Redis 安裝在 Server A，通過 172.16.254.18:6379 進行訪問，無密碼，安裝過程略，詳情參考 Redis 官方文檔。

#創(chuàng)建文件系統(tǒng)
juicefsformat--storageminio
--buckethttp://172.16.254.18:9000/test-juicefs
--access-keyadmin
--secret-keyabc123abc
--trash-days0
redis://172.16.254.18/1
myjfs

5.另外，我會同時以較為常用的 POSIX 和 S3 API 兩種方式訪問 JuiceFS 并分別測試它們的性能。

#創(chuàng)建掛載目錄
mkdir~/mnt-juicefs

#以POSIX方式掛載文件系統(tǒng)
juicefsmountredis://172.16.254.18/1/root/mnt-juicefs

#以S3API方式訪問文件系統(tǒng)
exportMINIO_ROOT_USER=admin
exportMINIO_ROOT_PASSWORD=abc123abc
juicefsgatewayredis://172.16.254.18/10.0.0.0:9000

#在mc中為JuiceFSS3API添加別名
mcaliassetjuicefshttp://172.16.254.18:9000adminabc123abc

注：JuiceFS Gateway 也可以部署在 Server A 或其他任何可聯(lián)網(wǎng)服務(wù)器上，因為它開放的是基于網(wǎng)絡(luò)訪問的 S3 API。

測試及結(jié)果

測試一：10GB 文件寫入測試

這項測試用來評估寫大文件的性能，耗時越短性能越好。這里會使用 time 命令統(tǒng)計寫入耗時，結(jié)果會包含三個指標(biāo)：

? real：從命令開始到結(jié)束的實際時間。它包括了所有的等待時間，例如等待 I/O 操作完成、等待進程切換、等待資源等。

? user：在用戶態(tài)（用戶模式）執(zhí)行的時間，也就是 CPU 用于執(zhí)行用戶代碼的時間。它通常表示命令的計算工作量。

? sys：在內(nèi)核態(tài)（系統(tǒng)模式）執(zhí)行的時間，也就是 CPU 用于執(zhí)行內(nèi)核代碼的時間。它通常表示命令與系統(tǒng)調(diào)用（如文件 I/O、進程管理等）相關(guān)的工作量。

MinIO

#執(zhí)行拷貝測試
timemccp./2018_Yellow_Taxi_Trip_Data.csvmy/test-minio/

MinIO 直寫 10 GB 文件的測試結(jié)果：

real0m27.651s
user0m10.767s
sys0m5.439s

s3fs-fuse

#執(zhí)行拷貝測試
timemccp./2018_Yellow_Taxi_Trip_Data.csv/root/mnt-s3fs/

s3fs-fuse 寫 10 GB 文件的測試結(jié)果：

real3m6.380s
user0m0.012s
sys0m5.459s

注：雖然寫入耗時 3 分零 6 秒，但并沒有出現(xiàn)那篇文章所謂寫入失敗的情況。

JuiceFS POSIX 和 S3 API

分別測試 JuiceFS 的 POSIX 和 S3 API 的大文件寫性能：

#POSIX寫測試
timemccp./2018_Yellow_Taxi_Trip_Data.csv/root/mnt-juicefs/

#S3API寫測試
timemccp./2018_Yellow_Taxi_Trip_Data.csvjuicefs/myjfs/

JuiceFS POSIX 寫 10 GB 文件的測試結(jié)果：

real0m28.107s
user0m0.292s
sys0m6.930s

JuiceFS S3 API 寫 10GB 文件的測試結(jié)果：

real0m28.091s
user0m13.643s
sys0m4.142s

大文件寫結(jié)果總結(jié)

大文件寫測試（值越小，性能越好）

從測試結(jié)果來看，直接寫 MinIO 和 JuiceFS 的性能相當(dāng)，均可在 30s 內(nèi)完成，而 s3fs-fuse 寫入 10GB 文件耗時 3 分鐘以上，平均比前兩者慢了 6 倍左右。

在寫入大文件時，mc 會使用 Multipart API 來將文件分塊上傳到 S3 接口，而只能單線程寫入到 POSIX。JuiceFS 在大文件的順序?qū)懸矔詣訉⑽募謮K并并發(fā)寫入到 MinIO 中，因此與直接寫 MinIO 性能相當(dāng)。而 S3FS 默認(rèn)先是單線程寫入到緩存盤，然后再分塊寫入到 MinIO 中，這會耗費更多寫入時間。

按照寫 10GB 文件耗時 30 秒計算，平均速度為 333 MB/s，這是云服務(wù)器 SSD 的帶寬限制，測試結(jié)果表明，MinIO 和 JuiceFS 都能打滿本地 SSD 的帶寬，它們的性能會隨著服務(wù)器云盤和網(wǎng)絡(luò)帶寬的提升而提升。

測試二：Pandas 小文件覆蓋寫

這項測試主要用來評估對象存儲在小文件覆蓋寫方面的性能，各個軟件的測試腳本略有不同，你可以在這里[3]找到所有腳本代碼。

Minio

#獲取測試腳本
curl-LOhttps://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-minio.py

#執(zhí)行測試
python3pandas-minio.py

測試結(jié)果：

Executiontime:0.83seconds

s3fs-fuse

#獲取測試腳本
curl-LOgist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-s3fs.py

#執(zhí)行測試
python3pandas-s3fs.py

測試結(jié)果：

Executiontime:0.78seconds

JuiceFS POSIX

#獲取測試腳本
curl-LOgist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-posix.py

#執(zhí)行測試
python3pandas-juicefs-posix.py

測試結(jié)果：

Executiontime:0.43seconds

JuiceFS S3 API

#獲取測試腳本
curl-LOhttps://gist.githubusercontent.com/yuhr123/7acb7e6bb42fb0ff12f3ba64d2cdd7da/raw/30c748e20b56dec642a58f9cccd7ea6e213dab3c/pandas-juicefs-s3api.py

#執(zhí)行測試
python3pandas-juicefs-s3api.py

測試結(jié)果：

Executiontime:0.86seconds

Pandas 小文件覆蓋寫結(jié)果總結(jié)

小文件覆蓋寫測試（值越小，性能越好）

在這項測試中，JuiceFS FUSE-POSIX 的速度最快，幾乎是其他方案的 2 倍。MinIO、s3fs-fuse、JuiceFS S3 Gateway 的速度相當(dāng)。從小文件覆蓋寫的角度來看，POSIX 接口效率更高，比對象存儲接口有更好的性能表現(xiàn)。

測試結(jié)果

分析和總結(jié)

問題一：S3FS 為什么這么慢？

從測試數(shù)據(jù)可以清楚地看到，寫入同樣的 10GB 大文件，S3FS 需要 3 分鐘，而 MinIO 和 JuiceFS 只需要 30 秒左右，速度相差近 6 倍，這主要是由于不同的技術(shù)實現(xiàn)導(dǎo)致的。

s3fs-fuse 在寫入文件時，會優(yōu)先寫入本地臨時文件，然后以分片方式上傳對象存儲。如果本地磁盤空間不足，則會以同步的方式上傳。因為它需要在本地磁盤和 S3 存儲之間進行數(shù)據(jù)復(fù)制，在處理大文件或大量文件時就會導(dǎo)致性能下降。

再者，S3FS 依賴底層對象存儲的元數(shù)據(jù)管理能力，當(dāng)需要讀寫大量文件時，頻繁地與對象存儲交互獲取元數(shù)據(jù)也會對性能產(chǎn)生很大的影響。

簡單來說，寫入 S3FS 的文件體積和總量越大，相應(yīng)的性能開銷也會成比例地放大。

問題二：JuiceFS 為什么更快？

同樣是通過 FUSE 進行讀寫，為什么 JuiceFS 可以與 MinIO 一樣打滿磁盤帶寬，而沒有像 S3FS 那樣出現(xiàn)性能問題呢？這同樣也是由技術(shù)架構(gòu)決定的。

在寫入文件時，數(shù)據(jù)雖然也經(jīng)由 FUSE 層處理，但 JuiceFS 通過高并發(fā)、緩存、數(shù)據(jù)分塊等技術(shù)降低了與底層對象存儲之間的通信開銷，一次性處理更多文件的讀寫請求，從而減少了等待時間和傳輸延遲。

另外，JuiceFS 采用獨立的數(shù)據(jù)庫（在本文中使用了 Redis）管理元數(shù)據(jù)，當(dāng)文件量特別大時，獨立的元數(shù)據(jù)引擎能有效釋放壓力，可以更快地定位文件位置。

結(jié)論

以上數(shù)據(jù)表明，把對象存儲作為底層，在其上實現(xiàn) POSIX 接口不一定會損失性能，不論是寫大文件還是小文件，JuiceFS 的性能與直接寫 MinIO 是相當(dāng)?shù)?，并沒有因為訪問 POSIX 而損失底層對象存儲的性能。而在 Pandas 表格覆蓋寫方面，JuiceFS FUSE-POSIX 的性能不降反升，超過 MinIO 近兩倍。

從測試結(jié)果不難發(fā)現(xiàn)，某些軟件（例如 s3fs-fuse）將 S3 API 與 POSIX 接口相互轉(zhuǎn)換可能會導(dǎo)致對象存儲的性能損失，但它不失為一款還算方便的臨時訪問 S3 的小工具，但要想長期穩(wěn)定的高性能使用，需要通過更為審慎的調(diào)研和驗證來選擇其他更適的方案。

簡單的非結(jié)構(gòu)化文件歸檔存儲，直接使用 MinIO 或云上對象存儲是不錯的選擇。而對于需要進行大規(guī)模數(shù)據(jù)存儲和處理，如 AI 模型訓(xùn)練、大數(shù)據(jù)分析和 Kubernetes 數(shù)據(jù)持久化等頻繁讀寫的場景，JuiceFS 的獨立元數(shù)據(jù)管理、并發(fā)讀寫和緩存機制會帶來更好的性能表現(xiàn)，是更值得嘗試的高性能文件系統(tǒng)解決方案。

審核編輯：劉清