seaweedfs
3.80
SeaweedFS 是一個獨立的 Apache 許可的開源項目，其持續開發的實現完全歸功於這些出色支持者的支持。如果您想讓 SeaweedFS 變得更強大，請考慮加入我們的 Patreon 贊助商。
我和其他支持者將非常感謝您的支持！
docker run -p 8333:8333 chrislusf/seaweedfs server -s3
weed或weed.exe 。或運行go install github.com/seaweedfs/seaweedfs/weed@latest 。weed server -dir=/some/data/dir -s3以啟動一台主伺服器、一台磁碟區伺服器、一台檔案管理器和一台 S3 閘道。另外，要增加容量，只需在本地、或在不同weed volume -dir="/some/data/dir2" -mserver="<master_host>:9333" -port=8081電腦上或在數千台機器上。就是這樣！
SeaweedFS 是一個簡單且高度可擴展的分散式檔案系統。有兩個目標：
SeaweedFS 最初是作為一個物件儲存來有效處理小檔案的。中央主機不管理中央主機中的所有文件元數據，而是僅管理卷伺服器上的捲，而這些卷伺服器管理文件及其元數據。這減輕了中央主伺服器的並發壓力，並將檔案元資料分散到磁碟區伺服器中，從而允許更快的檔案存取（O(1)，通常只需一次磁碟讀取操作）。
每個檔案的元資料僅需要 40 位元組的磁碟儲存開銷。 O(1) 磁碟讀取非常簡單，歡迎您用實際用例來挑戰性能。
SeaweedFS 首先實作了 Facebook 的 Haystack 設計論文。此外，SeaweedFS 也藉鑒了 f4（Facebook 的 Warm BLOB 儲存系統）的想法實現了糾刪碼，與 Facebook 的 Tectonic Filesystem 有許多相似之處
在物件儲存之上，可選的 Filer 可以支援目錄和 POSIX 屬性。 Filer 是一個獨立的線性可擴展無狀態伺服器，具有可自訂的元資料存儲，例如MySql、Postgres、Redis、Cassandra、HBase、Mongodb、Elastic Search、LevelDB、RocksDB、Sqlite、MemSql、TiDB、Etcd、CockroachDB、 YDB 等。
對於任何分散式鍵值存儲，可以將大值卸載到 SeaweedFS。 SeaweedFS 具有快速的存取速度和線性可擴展的容量，可作為分散式 Key-Large-Value 儲存。
SeaweedFS 可以透明地與雲端整合。熱數據位於本地集群，溫數據位於雲端上，存取時間為 O(1)，SeaweedFS 可實現快速的本地存取時間和彈性的雲端儲存容量。更重要的是，雲端儲存存取API成本被最小化。比直接雲端儲存更快、更便宜！
回目錄
回目錄
回目錄
預設情況下，主節點運行在連接埠9333 上，磁碟區節點運行在連接埠8080 上。 。我們將使用 localhost 作為範例。
SeaweedFS 使用 HTTP REST 操作來讀取、寫入和刪除。回應採用 JSON 或 JSONP 格式。
> ./weed master
> weed volume -dir="/tmp/data1" -max=5 -mserver="localhost:9333" -port=8080 &
> weed volume -dir="/tmp/data2" -max=10 -mserver="localhost:9333" -port=8081 &
要上傳檔案：首先，向/dir/assign發送 HTTP POST、PUT 或 GET 請求以取得fid和磁碟區伺服器 URL：
> curl http://localhost:9333/dir/assign
{"count":1,"fid":"3,01637037d6","url":"127.0.0.1:8080","publicUrl":"localhost:8080"}
其次，要儲存檔案內容，請從回應中向url + '/' + fid發送 HTTP 多部分 POST 請求：
> curl -F file=@/home/chris/myphoto.jpg http://127.0.0.1:8080/3,01637037d6
{"name":"myphoto.jpg","size":43234,"eTag":"1cc0118e"}
若要更新，請傳送另一個包含更新的文件內容的 POST 請求。
若要刪除，請向相同的url + '/' + fid URL 傳送 HTTP DELETE 請求：
> curl -X DELETE http://127.0.0.1:8080/3,01637037d6
現在，您可以將fid （本例中為 3,01637037d6）儲存到資料庫欄位。
開頭的數字 3 代表卷數 ID。逗號後面是一個檔案金鑰 01 和一個檔案 cookie 637037d6。
卷 ID 是一個無符號 32 位元整數。文件密鑰是一個無符號 64 位元整數。檔案cookie是一個無符號的32位元整數，用來防止URL猜測。
文件金鑰和檔案 cookie 均以十六進位編碼。您可以以您自己的格式儲存 <volume id, file key, file cookie> 元組，或簡單地將fid儲存為字串。
如果儲存為字串，理論上需要 8+1+16+8=33 個位元組。一個 char(33) 就足夠了，因為大多數用途不需要 2^32 卷。
如果空間確實是一個問題，您可以以自己的格式儲存檔案 ID。您需要一個 4 位元組整數作為磁碟區 id，一個 8 位元組長數字作為檔案金鑰，以及一個 4 位元組整數作為檔案 cookie。所以16個位元組就夠了。
以下是如何呈現 URL 的範例。
首先透過檔案的volumeId查找卷宗伺服器的URL：
> curl http://localhost:9333/dir/lookup?volumeId=3
{"volumeId":"3","locations":[{"publicUrl":"localhost:8080","url":"localhost:8080"}]}
由於（通常）沒有太多磁碟區伺服器，且磁碟區不經常移動，因此您可以在大多數情況下快取結果。根據複製類型，一個磁碟區可以有多個副本位置。只需隨機選擇一個位置進行閱讀即可。
現在您可以取得公用 URL、渲染 URL 或透過 URL 直接從磁碟區伺服器讀取：
http://localhost:8080/3,01637037d6.jpg
請注意，我們在此處新增了檔案副檔名“.jpg”。它是可選的，並且只是客戶端指定文件內容類型的一種方式。
如果您想要更好的 URL，可以使用以下替代 URL 格式之一：
http://localhost:8080/3/01637037d6/my_preferred_name.jpg
http://localhost:8080/3/01637037d6.jpg
http://localhost:8080/3,01637037d6.jpg
http://localhost:8080/3/01637037d6
http://localhost:8080/3,01637037d6
如果你想獲得圖像的縮放版本，你可以添加一些參數：
http://localhost:8080/3/01637037d6.jpg?height=200&width=200
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fit
http://localhost:8080/3/01637037d6.jpg?height=200&width=200&mode=fill
SeaweedFS 在磁碟區層級應用複製策略。因此，當您取得檔案 ID 時，您可以指定複製策略。例如：
curl http://localhost:9333/dir/assign?replication=001
複製參數選項有：
000: no replication
001: replicate once on the same rack
010: replicate once on a different rack, but same data center
100: replicate once on a different data center
200: replicate twice on two different data center
110: replicate once on a different rack, and once on a different data center
有關複製的更多詳細資訊可以在 wiki 上找到。
您也可以在啟動主伺服器時設定預設複製策略。
磁碟區伺服器可以使用特定的資料中心名稱啟動：
weed volume -dir=/tmp/1 -port=8080 -dataCenter=dc1
weed volume -dir=/tmp/2 -port=8081 -dataCenter=dc2
當請求檔案金鑰時，可選的「dataCenter」參數可以將指派的磁碟區限製到特定的資料中心。例如，這指定分配的磁碟區應限制為“dc1”：
http://localhost:9333/dir/assign?dataCenter=dc1
回目錄
通常分散式檔案系統會將每個檔案分割成區塊，中央主機保存檔案名稱、區塊索引到區塊句柄的映射，以及每個區塊伺服器擁有哪些區塊。
主要缺點是中央主控無法有效地處理許多小文件，並且由於所有讀取請求都需要經過區塊主控，因此對於許多並髮用戶來說它可能無法很好地擴展。
SeaweedFS 不管理區塊，而是管理主伺服器中的資料磁碟區。每個資料磁碟區大小為32GB，可容納大量檔案。並且每個儲存節點可以有很多資料卷。所以主節點只需要儲存有關磁碟區的元數據，這是一個相當小的資料量，而且通常是穩定的。
實際的文件元資料儲存在卷伺服器上的每個卷中。由於每個卷伺服器只管理自己磁碟上的文件元數據，每個文件只有16字節，因此所有文件存取都可以直接從記憶體中讀取文件元數據，只需要一次磁碟操作即可真正讀取文件數據。
為了進行比較，請考慮 Linux 中的 xfs inode 結構為 536 位元組。
該架構相當簡單。實際資料儲存在儲存節點上的磁碟區。一台卷伺服器可以有多個卷，並且可以透過基本身份驗證支援讀取和寫入存取。
所有磁碟區均由主伺服器管理。主伺服器包含磁碟區 ID 到磁碟區伺服器的對應。這是相當靜態的訊息，可以輕鬆緩存。
對於每個寫入請求，主伺服器也會產生一個檔案金鑰，它是一個不斷增長的 64 位元無符號整數。由於寫入請求通常不像讀取請求那麼頻繁，因此一台主伺服器應該能夠很好地處理並發性。
當客戶端發送寫入請求時，主伺服器會傳回該檔案的（磁碟區 ID、檔案金鑰、檔案 cookie、磁碟區節點 URL）。然後，客戶端聯繫卷節點並 POST 檔案內容。
當用戶端需要基於（磁碟區 id、檔案金鑰、檔案 cookie）讀取檔案時，它會透過磁碟區 id 向主伺服器詢問（磁碟區節點 URL、磁碟區節點公用 URL），或從快取擷取該檔案。然後用戶端可以取得內容，或只是在網頁上呈現 URL，讓瀏覽器取得內容。
有關寫入-讀取過程的詳細信息，請參閱範例。
在目前實作中，每個磁碟區可以容納 32 GB（32GiB 或 8x2^32 位元組）。這是因為我們將內容對齊到 8 位元組。透過更改 2 行程式碼，我們可以輕鬆地將其增加到 64GiB、128GiB 或更多，但代價是由於對齊而浪費了一些填充空間。
可以有 4 GB（4GiB 或 2^32 位元組）的磁碟區。因此系統總大小為 8 x 4GiB x 4GiB，即 128 exbibytes（128EiB 或 2^67 位元組）。
每個單獨的檔案大小都受到磁碟區大小的限制。
儲存在磁碟區伺服器上的所有檔案元資訊都可以從記憶體中讀取，無需存取磁碟。每個檔案僅採用 <64 位元密鑰、32 位元偏移量、32 位元大小> 的 16 位元組映射條目。當然，每個地圖條目都有自己的地圖空間成本。但通常磁碟空間先於記憶體耗盡。
本地捲伺服器速度要快得多，而雲端儲存具有彈性容量，如果不經常存取（通常免費上傳，但存取成本相對較高），實際上更具成本效益。憑藉僅附加結構和 O(1) 存取時間，SeaweedFS 可以透過將熱資料卸載到雲端來利用本地和雲端儲存。
通常熱數據是新鮮的，溫數據是舊的。 SeaweedFS 將新建立的磁碟區放在本機伺服器上，並可選擇將舊磁碟區上傳到雲端。如果較舊的資料存取頻率較低，這實際上可以透過有限的本地伺服器為您提供無限的容量，並且對於新資料來說仍然很快。
存取時間為 O(1)，網路延遲成本維持在最低水準。
如果熱/溫資料依照20/80分割，使用20台伺服器，可以實現100台伺服器的儲存容量。這相當於節省了 80% 的成本！或者，您也可以重新調整 80 台伺服器的用途來儲存新數據，並獲得 5 倍的儲存吞吐量。
回目錄
大多數其他分散式檔案系統似乎比必要的更複雜。
SeaweedFS 的設定和操作都旨在快速且簡單。如果你到達這裡時還不明白它是如何運作的，我們就失敗了！請提出任何問題或更新此文件並進行澄清。
SeaweedFS 不斷前進。與其他系統相同。這些比較可能很快就會過時。請幫助保持更新。
回目錄
HDFS對每個檔案使用區塊方法，非常適合儲存大檔案。
SeaweedFS 非常適合快速並發地處理相對較小的檔案。
SeaweedFS 還可以透過將超大文件分割成可管理的資料區塊來儲存超大文件，並將資料區塊的文件 ID 儲存到元區塊中。這是由“雜草上傳/下載”工具管理的，雜草主控或卷伺服器對此不可知。
回目錄
這些架構大部分是相同的。 SeaweedFS 旨在透過簡單、扁平的架構快速儲存和讀取檔案。主要區別是
| 系統 | 文件元數據 | 文件內容讀取 | POSIX | 休息API | 針對大量小文件進行了最佳化 |
|---|---|---|---|---|---|
| 海藻FS | 查找卷 ID，可緩存 | O(1) 磁碟尋道 | 是的 | 是的 | |
| SeaweedFS 檔案管理器 | 可線性擴展、可自訂 | O(1) 磁碟尋道 | 保險絲 | 是的 | 是的 |
| GlusterFS | 散列 | 保險絲、NFS | |||
| 頭孢 | 哈希+規則 | 保險絲 | 是的 | ||
| 穆斯FS | 記憶中 | 保險絲 | 不 | ||
| 最小IO | 每個文件都有單獨的元文件 | 是的 | 不 |
回目錄
GlusterFS 將檔案（包括目錄和內容）儲存在稱為「bricks」的可設定磁碟區中。
GlusterFS 將路徑和檔案名稱散列到 ids 中，並指派給虛擬卷，然後對應到「bricks」。
回目錄
MooseFS選擇忽略小檔案問題。根據moosefs 3.0 手冊，“即使是一個小文件也會佔用64KiB 加上另外4KiB 的校驗和和1KiB 的標頭”，因為它“最初是為保存大量（如數千個）非常大的文件而設計的”
MooseFS 主伺服器將所有元資料保存在記憶體中。與 HDFS namenode 相同的問題。
回目錄
Ceph 可以像 SeaweedFS 一樣設定為 key->blob 儲存。它要複雜得多，需要在其之上支援層。這是更詳細的比較
SeaweedFS 有一個集中的主群組來尋找空閒卷，而 Ceph 使用雜湊和元資料伺服器來定位其物件。擁有集中式主機可以輕鬆編碼和管理。
Ceph 與 SeaweedFS 一樣，基於物件儲存 RADOS。 Ceph 相當複雜，評論褒貶不一。
Ceph使用CRUSH雜湊來自動管理資料放置，可以有效率地定位資料。但數據必須按照CRUSH演算法來放置。任何錯誤的配置都會導致資料遺失。拓撲變化，例如添加新伺服器以增加容量，將導致高IO成本的資料遷移以適應CRUSH演算法。 SeaweedFS 透過將資料指派給任何可寫磁碟區來放置資料。如果寫入一個磁碟區失敗，只需選擇另一個磁碟區進行寫入。添加更多卷也非常簡單。
SeaweedFS 針對小檔案進行了最佳化。小檔案儲存為一個連續的內容區塊，檔案之間最多有 8 個未使用的位元組。小檔案存取是 O(1) 磁碟讀取。
SeaweedFS Filer 使用現成的儲存空間來管理檔案目錄，例如 MySql、Postgres、Sqlite、Mongodb、Redis、Elastic Search、Cassandra、HBase、MemSql、TiDB、CockroachCB、Etcd、YDB。這些商店經過驗證、可擴展且更易於管理。
| 海藻FS | 與 Ceph 相當 | 優勢 |
|---|---|---|
| 掌握 | MDS | 更簡單 |
| 體積 | 螢幕顯示 | 針對小文件進行了優化 |
| 銼刀 | 頭孢FS | 線性可擴充、可自訂、O(1) 或 O(logN) |
回目錄
MinIO 緊密遵循 AWS S3，非常適合測試 S3 API。它具有良好的 UI、策略、版本控制等。也可以稍後將MinIO當作網關放在SeaweedFS前面。
MinIO 元資料位於簡單檔案中。每個文件寫入都會對對應的元文件產生額外的寫入。
MinIO 並沒有針對大量小檔案進行最佳化。文件只是按原樣儲存到本機磁碟。再加上額外的元檔案和糾刪碼分片，只會加劇 LOSF 問題。
MinIO有多個磁碟IO來讀取一個檔案。 SeaweedFS 的磁碟讀取速度為 O(1)，即使對於糾刪碼檔案也是如此。
MinIO 具有全時擦除編碼。 SeaweedFS 對熱資料使用複製以提高速度，並可選擇對熱資料套用糾刪碼。
MinIO 沒有類似 POSIX 的 API 支援。
MinIO對儲存佈局有特定的要求。容量調整不靈活。在 SeaweedFS 中，只需啟動一台指向主伺服器的磁碟區伺服器。就這樣。
這是一個超級令人興奮的項目！我們需要幫助和支持！
回目錄
不熟悉golang的使用者安裝指南
步驟 1：在您的電腦上安裝 go 並按照以下說明設定環境：
https://golang.org/doc/install
確保定義你的 $GOPATH
第 2 步：簽出此儲存庫：
git clone https://github.com/seaweedfs/seaweedfs.git第三步：執行以下指令下載、編譯、安裝項目
cd seaweedfs/weed && make install完成此操作後，您將在$GOPATH/bin目錄中找到可執行檔“weed”
回目錄
在SeaweedFS上測試讀取效能時，它基本上變成了對硬碟隨機讀取速度的效能測試。硬碟通常可達 100MB/s~200MB/s。
若要修改或刪除小文件，SSD 必須一次刪除整個區塊，並將現有區塊中的內容移至新區塊。全新的 SSD 速度很快，但隨著時間的推移會變得碎片化，你必須進行垃圾收集、壓縮區塊。 SeaweedFS 對 SSD 友好，因為它是僅追加的。刪除和壓縮是在後台按音量等級完成的，不會減慢讀取速度，也不會造成碎片。
回目錄
我自己在固態碟盤的Mac Book上得到的不科學的單機結果，CPU：1個Intel Core i7 2.6GHz。
寫入100萬個1KB檔：
Concurrency Level: 16
Time taken for tests: 66.753 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106789009 bytes
Requests per second: 15708.23 [#/sec]
Transfer rate: 16191.69 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.3 1.0 84.3 0.9
Percentage of the requests served within a certain time (ms)
50% 0.8 ms
66% 1.0 ms
75% 1.1 ms
80% 1.2 ms
90% 1.4 ms
95% 1.7 ms
98% 2.1 ms
99% 2.6 ms
100% 84.3 ms
隨機讀取100萬個檔案：
Concurrency Level: 16
Time taken for tests: 22.301 seconds
Completed requests: 1048576
Failed requests: 0
Total transferred: 1106812873 bytes
Requests per second: 47019.38 [#/sec]
Transfer rate: 48467.57 [Kbytes/sec]
Connection Times (ms)
min avg max std
Total: 0.0 0.3 54.1 0.2
Percentage of the requests served within a certain time (ms)
50% 0.3 ms
90% 0.4 ms
98% 0.6 ms
99% 0.7 ms
100% 54.1 ms
make benchmark
warp: Benchmark data written to "warp-mixed-2023-10-16[102354]-l70a.csv.zst"
Mixed operations.
Operation: DELETE, 10%, Concurrency: 20, Ran 4m59s.
* Throughput: 6.19 obj/s
Operation: GET, 45%, Concurrency: 20, Ran 5m0s.
* Throughput: 279.85 MiB/s, 27.99 obj/s
Operation: PUT, 15%, Concurrency: 20, Ran 5m0s.
* Throughput: 89.86 MiB/s, 8.99 obj/s
Operation: STAT, 30%, Concurrency: 20, Ran 5m0s.
* Throughput: 18.63 obj/s
Cluster Total: 369.74 MiB/s, 61.79 obj/s, 0 errors over 5m0s.
要查看分段請求統計信息，請使用 --analyze.v 參數。
warp analyze --analyze.v warp-mixed-2023-10-16[102354]-l70a.csv.zst
18642 operations loaded... Done!
Mixed operations.
----------------------------------------
Operation: DELETE - total: 1854, 10.0%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 6.19 obj/s
Requests considered: 1855:
* Avg: 104ms, 50%: 30ms, 90%: 207ms, 99%: 1.355s, Fastest: 1ms, Slowest: 4.613s, StdDev: 320ms
----------------------------------------
Operation: GET - total: 8388, 45.3%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.12 +0500 +05
* Throughput: 279.77 MiB/s, 27.98 obj/s
Requests considered: 8389:
* Avg: 221ms, 50%: 106ms, 90%: 492ms, 99%: 1.739s, Fastest: 8ms, Slowest: 8.633s, StdDev: 383ms
* TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 171ms, 99th: 669ms, Worst: 4.783s StdDev: 163ms
* First Access: Avg: 240ms, 50%: 105ms, 90%: 511ms, 99%: 2.08s, Fastest: 12ms, Slowest: 8.633s, StdDev: 480ms
* First Access TTFB: Avg: 88ms, Best: 2ms, 25th: 24ms, Median: 38ms, 75th: 64ms, 90th: 179ms, 99th: 919ms, Worst: 4.783s StdDev: 199ms
* Last Access: Avg: 219ms, 50%: 106ms, 90%: 463ms, 99%: 1.782s, Fastest: 9ms, Slowest: 8.633s, StdDev: 416ms
* Last Access TTFB: Avg: 81ms, Best: 2ms, 25th: 24ms, Median: 39ms, 75th: 65ms, 90th: 161ms, 99th: 657ms, Worst: 4.783s StdDev: 176ms
----------------------------------------
Operation: PUT - total: 2688, 14.5%, Size: 10485760 bytes. Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.115 +0500 +05
* Throughput: 89.83 MiB/s, 8.98 obj/s
Requests considered: 2689:
* Avg: 1.165s, 50%: 878ms, 90%: 2.015s, 99%: 5.74s, Fastest: 99ms, Slowest: 8.264s, StdDev: 968ms
----------------------------------------
Operation: STAT - total: 5586, 30.2%, Concurrency: 20, Ran 5m0s, starting 2023-10-16 10:23:57.113 +0500 +05
* Throughput: 18.63 obj/s
Requests considered: 5587:
* Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 80ms, Fastest: 0s, Slowest: 245ms, StdDev: 17ms
* First Access: Avg: 14ms, 50%: 10ms, 90%: 33ms, 99%: 69ms, Fastest: 0s, Slowest: 203ms, StdDev: 16ms
* Last Access: Avg: 15ms, 50%: 11ms, 90%: 34ms, 99%: 74ms, Fastest: 0s, Slowest: 203ms, StdDev: 17ms
Cluster Total: 369.64 MiB/s, 61.77 obj/s, 0 errors over 5m0s.
Total Errors:0.
回目錄
根據 Apache 許可證 2.0 版（“許可證”）獲得許可；除非遵守許可證，否則您不得使用此文件。您可以在以下位置取得許可證副本：
http://www.apache.org/licenses/LICENSE-2.0
除非適用法律要求或書面同意，否則根據許可證分發的軟體均以「原樣」分發，不帶任何明示或暗示的保證或條件。請參閱許可證，了解許可證下管理權限和限制的特定語言。
本頁的文字可根據 Creative Commons Attribution-Sharealike 3.0 Unported License 和 GNU Free Documentation License（無版本，沒有不變部分、封面文字或封底文字）的條款進行修改和重複使用。
回目錄
