文件系統是計算機中一個非常重要的組件，為存儲設備提供一致的訪問和管理方式。在不同的操作系統中，文件系統會有一些差別，但也有一些共性幾十年都沒怎麼變化：文件以樹形目錄進行組織；
數據是以文件的形式存在，提供 Open、Read、Write、Seek、Close 等API 進行訪問；
提供原子的重命名（Rename）操作改變文件或者目錄的位置。文件系統提供的訪問和管理方法支撐了絕大部分的計算機應用，Unix 的「萬物皆文件」的理念更是凸顯了它的重要地位。JuiceFS 是一款開源分布式文件系統，創新的將對象存儲作為底層存儲介質，實現了存儲空間的無限擴展。任何存入 JuiceFS 的文件都會按照特定規則被拆分成固定大小的數據塊保存在對象存儲，數據塊的元數據則保存在 Redis、MySQL 等數據庫中。OSCHINA 請來了 Juicedata 合伙人蘇銳和大家一起探討關於分布式文件系統相關的問題。嘉賓簡介蘇銳，Juicedata 合伙人，作為1號成員參與創建分布式文件系統 JuiceFS，先通過全球公有雲上的 SaaS 產品獲得國內外幾十家商業客戶，之後於 2021 年 1 月 JuiceFS 開源。問：JuiceFS 是依賴 redis、mysql 什麼版本呢？如何考慮系統安全問題呢？答：Redis 可以參考最佳實踐（https://juicefs.com/docs/zh/community/redis_best_practices/），各種引擎用流行的版本都能支持，JuiceFS 會儘量兼容更多的引擎和版本。問：JuiceFS 的對象存儲相對傳統的塊存儲分布式文件系統有啥優點？JuiceFS 的存儲現在是針對什麼業務場景使用的？答：JuiceFS 是一個 object-based 的分布式文件系統，相比 block-based 有更好的彈性。Object Storage 可以認為是完全彈性的，但是 Block Storage 大多做不到。目前 JuiceFS 主要用在 大數據、AI、DevOps 和各種需要 NAS 的應用場景，在 juicefs.com 上可以看到很多案例和客戶實踐。問：如果文件被拆分成固定大小的數據塊，那這些數據塊是怎麼保證順序的，以及數據庫塊的大小是固定的嗎？會不會出現大量的內存碎片？讀取的時候是不是要占用大量內存進行合併數據庫 ？答：比如想讀 1GB 的文件，在存儲中是 sequential read。如果全部讀出來返回給請求端，更占內存，調用端的等待時間更長。都是 4K/64K/256K/1M 等容量去順序讀，以一個 streaming 的方式持續返回給調用端。所以 JuiceFS 把文件分成 block 存儲不會影響性能。相反，還能提升性能。因為更容易通過並發方式同時讀很多的 block 返回給調用端，當然獲得高吞吐的同時，需要用一點內存資源來換。文件被分成很多 data block 存在對象存儲中，每個 block key 會存在 meta engine 里（直接存太占空間了，設計上 16 個 block 為一個 chunk，存儲 chunkid + offset）。block size 默認設為 4MiB 是最大值，實際會有小於該值的 block。碎片合併有的。讀取的時候不用擔心，各種存儲系統在讀的時候也都是按某個大小的 page/block 去讀。問：考慮到存取速度、修復難度以及遷移，對於底層文件系統的選擇有什麼推薦的嗎？答：存取速度容易判斷，結合你的業務場景來測試評估就行了。我想說的是在分布式存儲中，只用一些 Benchmark Tool 來看跑分和實際業務場景中的表現是有不同的，一定用業務場景來測試。遷移方面，通用流行的訪問協議都不難，比如 JuiceFS 完全兼容 POSIX、HDFS、S3，還提供 juicesync 這個數據遷移工具，兼容幾十種對象存儲的 API。要考慮的是數據遷移中，業務的影響。問：JuiceFS 的跨節點、機架、機房、區域的副本放置策略，可用性程度，能不能簡單講講：一致性協議的實現以及涉及到元數據管理，主叢切換的及時性和正確性，最後就是各種突發情況下主從同步的策略，全面高效的負載均衡(空間/吞吐/副本)。答：JuiceFS 社區版使用流行的數據庫引擎，包括 Redis、MySQL、PostgreSQL、TiKV 這些，每一個都有很多運維的實踐經驗。部署和運維的方案都用這些數據庫引擎社區推薦的，必要的地方 JuiceFS 會提供一些最佳實踐，比如使用 Redis 做元數據引擎。問：JuiceFS 是否提供開放 Key-Value Storage 的 API 接口，以及有哪些支持的程序設計語言？另外，對於有大量小文件寫入的效率如何？答：可以用 S3 API 讀寫 JuiceFS 數據，參考文檔，如果以 POSIX 方式訪問，各種編程語言都原生支持了。編程語言的 SDK 目前有 Java SDK（是兼容 HDFS API 的）。答：JuiceFS 的優勢所在，參照文檔：https://juicefs.com/docs/zh/community/s3_gateway/。問：1.JuiceFS和 NAS NFS 存儲有啥區別？JuiceFS 優勢在哪裡？2.JuiceFS 使用了什麼設計模式？答：1. 相比 NAS，JuiceFS 為雲環境設計；彈性容量；更豐富的訪問方式，包括 POSIX、HDFS、S3、K8s CSI；在 大數據、AI、DevOps 和眾多需要 NAS 的場景上都適用，更高性價比 2. 參考架構設計採用元數據與數據分離的設計方案。問：同 Ceph 是一類產品嗎？如果是優勢在哪裡？答：和 CephFS 是一類產品，詳情可以參考文檔：https://juicefs.com/docs/zh/community/benchmark/。問：看了一篇利用 JuiceFS 實現 mysql 數據備份性能提升 10 倍的文章 裡面用到的 JuiceFS 自帶的性能分析工具真的不錯，希望老師能分享下它的設計和架構。答：可以參考文檔：https://juicefs.com/docs/zh/community/comparison/juicefs_vs_cephfs，然後再去看對應的代碼實現。答：JuiceFS 可以應用於大數據、AI、容器平台、DevOps 等場景，具體可以參考文檔：https://juicefs.com/docs/zh/cloud/how_to。問：在官方文檔中看到了 JuiceFS 和 Ceph、Alluxio 等產品的對比，但是感覺實際中的競爭對手可能是 MinIO 或者 OZone，請問是否做過與這2個產品的對比呢？最近在做對象存儲的技術調研，主要是存儲照片、音視頻和文本文件等，麻煩給一些意見，感謝！答：MinIO 和 OZone 都是對象存儲。JuiceFS 是文件系統，可以使用他倆做後端的持久層服務。如果您的需求是存儲和訪問，沒有計算、分析、訓練等場景，應該直接用對象存儲更適合。問：請問下 JuiceFS 對於海量的小文件存儲適合嗎？性能如何？客戶有歷史文件，包括上億的文件夾和文件。答：使用 Redis 做元數據引擎推薦存儲 2億以內文件，使用 TiKV 適合更大規模。性能要看場景，對於訓練等讀為主的場景有 cache 機制加速，性能不錯。如果 1 億文件 Redis，MySQL，TiKV 都沒有問題。要看你對哪個系統更熟悉，更有維護經驗。性能方面要看業務場景、訪問方式來做判斷。問：請問在底層實現上是如何保證分布式文件系統的文件完整性的？答：簡單說幾點：1. 先寫數據再寫元數據，保證元數據寫成功則數據完整；2. 元數據這邊靠引擎的事務性來保證完整；3. 寫進去之後 數據和元數據本身的可靠性分別依賴對象存儲和元數據引擎來保證；4. 會使用對象存儲提供的 checksum 能力。問：這個是類似 Fastdfs 做文件存儲的嗎，有什麼區別現在企業中哪個好用？答：JuiceFS 面向雲環境設計，在雲環境中可以很容易用起來，也天然的做到彈性伸縮。在訪問時支持 POSIX、HDFS、S3，在上面做應用開發更方便，尤其是組織各種 Pipeline。問：如果數據庫壞了，恢復了比如說一天前的備份，文件數據也能確保恢復到一天前的狀態，並能持續工作下去嗎？答：可以部分恢復，各種數據庫也都有更細粒度的容災方案，比如 Redis AOF、MySQL Binlog，可以最大限度減少數據丟失風險。另一方面，生產環境上也會用主備策略。數據刪除後，無論是元數據還是對象存儲中的數據都會被刪除。如果元數據恢復到之前一天的狀態，數據不能被恢復，也是讀不出來的。問：有沒有可能，在對象存儲中也存一個類似 binlog 的概念的日誌，當數據庫數據丟失又未備份時，可以通過這個類似 binlog 的結構，還原整個數據庫？答：新版上增加了自動備份元數據到對象存儲的功能，算是多一個備份。問：我認為，分布式文件系統，依賴於關係型數據庫，是設計思路錯誤。正確的應該是反過來，關係型數據庫，依賴於分布式文件系統。這樣，單個數據庫中，對應的後台硬盤空間是無限的。無論應用系統有多少容量的數據，關係型數據庫都可以在不分庫、不分表的情況下，通過增加新磁盤、調整分布式文件系統配置參數，來解決問題。不知道蘇老師怎麼看？答：理解您的說法，我也部分認可。JuiceFS 的架構設計在 High level 上與 Google File System 的那篇論文一直，採用元數據與數據分離管理的方式，也有很多其他的分布式文件系統用了這個思路。不同的地方時，在 Low level design 中，目前看到的大部分 DFS 面向裸磁盤設計。但是放在雲時代，我們重新抽象的去看這個問題，再結合我們自己十餘年使用 DFS 的業務經驗。DFS 承載了非常豐富的 Workload，對於規模、性能、持久性、可用性、成本等不同維度的要求是不一樣的。我們嘗試回答一個問題：如何用一個產品更好、更靈活的滿足更多、更豐富的業務場景？然後，在 JuiceFS 的架構設計上，選擇用對象存儲做數據持久層（類似 chunk server，data node），因為對象存儲提供了成熟的 scalebility、availibility、high throughput、low cost 三方面的優勢，這正是數據持久層需要的核心能力。元數據引擎做了插件式設計，Redis、MySQL、TiKV、FoundationDB 等有各自的優勢，能滿足不同的業務場景需求。選擇這些成熟、流行的系統，另一個好處是在開發者中已經積累了大量的使用和運維經驗，不用增加學習負擔。這是 JuiceFS 設計社區產品的理念，友好的使用體驗，低學習門檻，合適但無需極致（我們另有極致版的設計）。cURL作者吐槽：某財富500強 「白嫖」 技術支持中美開源差距究竟在哪微軟公布VS Code Java 2022年路線圖
覺得不錯，請點個在看呀
留言列表
留言列表