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

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

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

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

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

測(cè)試項(xiàng)目

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

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

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

在本文中，我會(huì)對(duì) MinIO、JuiceFS 和 s3fs-fuse 進(jìn)行以下兩項(xiàng)測(cè)試：

1.10GB 大文件的寫入測(cè)試

2.Pandas 小文件覆蓋寫測(cè)試

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

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

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

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

?System: Ubuntu 22.04 x64

?CPU: 8 cores

?RAM: 16GB

?SSD: 500GB

?Network: VPC

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

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

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

#創(chuàng)建并進(jìn)入專用目錄
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)建三個(gè) buckets：

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

下載 10GB 測(cè)試樣本文件

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

2.安裝 mc 客戶端

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

注：為了保持測(cè)試的公平性，三種方案均采用 mc 進(jìn)行寫測(cè)試。

#下載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è)置對(duì)象存儲(chǔ)訪問密鑰
echoadmin:abc123abc>~/.passwd-s3fs

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

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

#掛載對(duì)象存儲(chǔ)
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)建才能使用。除了對(duì)象存儲(chǔ)，還需要一個(gè)數(shù)據(jù)庫(kù)作為元數(shù)據(jù)引擎，支持多種數(shù)據(jù)庫(kù)，這里使用較常用的 Redis 作為元數(shù)據(jù)引擎。

注：我在這里將 Redis 安裝在 Server A，通過 172.16.254.18:6379 進(jìn)行訪問，無密碼，安裝過程略，詳情參考 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.另外，我會(huì)同時(shí)以較為常用的 POSIX 和 S3 API 兩種方式訪問 JuiceFS 并分別測(cè)試它們的性能。

#創(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ù)器上，因?yàn)樗_放的是基于網(wǎng)絡(luò)訪問的 S3 API。

測(cè)試及結(jié)果

測(cè)試一：10GB 文件寫入測(cè)試

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

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

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

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

MinIO

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

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

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

s3fs-fuse

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

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

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

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

JuiceFS POSIX 和 S3 API

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

#POSIX寫測(cè)試
timemccp./2018_Yellow_Taxi_Trip_Data.csv/root/mnt-juicefs/

#S3API寫測(cè)試
timemccp./2018_Yellow_Taxi_Trip_Data.csvjuicefs/myjfs/

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

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

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

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

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

大文件寫測(cè)試（值越小，性能越好）

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

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

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

測(cè)試二：Pandas 小文件覆蓋寫

這項(xiàng)測(cè)試主要用來評(píng)估對(duì)象存儲(chǔ)在小文件覆蓋寫方面的性能，各個(gè)軟件的測(cè)試腳本略有不同，你可以在這里[3]找到所有腳本代碼。

Minio

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

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

測(cè)試結(jié)果：

Executiontime:0.83seconds

s3fs-fuse

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

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

測(cè)試結(jié)果：

Executiontime:0.78seconds

JuiceFS POSIX

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

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

測(cè)試結(jié)果：

Executiontime:0.43seconds

JuiceFS S3 API

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

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

測(cè)試結(jié)果：

Executiontime:0.86seconds

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

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

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

測(cè)試結(jié)果

分析和總結(jié)

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

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

s3fs-fuse 在寫入文件時(shí)，會(huì)優(yōu)先寫入本地臨時(shí)文件，然后以分片方式上傳對(duì)象存儲(chǔ)。如果本地磁盤空間不足，則會(huì)以同步的方式上傳。因?yàn)樗枰诒镜卮疟P和 S3 存儲(chǔ)之間進(jìn)行數(shù)據(jù)復(fù)制，在處理大文件或大量文件時(shí)就會(huì)導(dǎo)致性能下降。

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

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

問題二：JuiceFS 為什么更快？

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

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

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

結(jié)論

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

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

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

審核編輯：劉清