Weedfs分散ファイルシステムの概要

紹介する
Seaweedfsは単純で拡張性の高い分散型ファイルシステムであり、その2つの目標はそれぞれ:

数十億のファイルを格納

クイックレスポンスファイル.

seaweedfsはキー値ペア(key->file)で実装する方法を選択します.これは「NoSQL」に似ています.「NoFS」として記述できます.
seaweedfsのセンタノード(center master)は、すべてのファイルのメタデータを管理するのではなく、ファイルボリューム(file volmume)のみを管理し、ファイルとそのメタデータの管理はvolume serverによって実現される.これにより、center masterの同時圧力が緩和され、volume serverにファイルメタデータを割り当てることで、ディスク読み取り操作を1回だけ行うことで、より高速なファイルアクセスが可能になります.
スキーマ＃スキーマ＃
通常、分散ファイルシステムは、各ファイルをブロックに分割し、中央プライマリサーバはファイル名を保持し、ブロックハンドルへのブロックインデックス、および各ブロックサーバが持つブロックを保持します.
主な欠点は、中央プライマリ・サーバが多くの小さなファイルを効率的に処理できず、すべての読み取り要求がブロック・プライマリ・サーバを通過する必要があるため、多くの同時ユーザにとってうまく拡張できない可能性があることです.
SeaweedFSは、管理ブロックではなくプライマリ・サーバ内のデータ・ボリュームを管理します.各データボリュームのサイズは32 GBで、大量のファイルを収容できます.各ストレージノードには、多くのデータボリュームがあります.したがって、プライマリノードは、ボリュームに関するメタデータを格納するだけで、これはかなりの量のデータであり、通常は安定している.
実際のファイルメタデータは、ボリュームサーバ上の各ボリュームに格納されます.各ボリューム・サーバは自分のディスク上のファイルのメタデータのみを管理し、各ファイルのメタデータは16バイトしかないため、すべてのファイル・アクセスはメモリからファイル・メタデータを読み取ることができ、ディスク操作を1回で実際にファイル・データを読み取ることができます.
プライマリ・サーバ(master server)とボリューム・サーバ(volmue server)
このアーキテクチャは非常に簡単です.実際のデータは、ストレージノードのボリュームに格納されます.1つのボリューム・サーバに複数のボリュームがあり、基本認証の読み書きアクセスをサポートできます.
すべてのボリュームはプライマリ・サーバによって管理されます.プライマリ・サーバには、ボリュームIDがボリューム・サーバにマッピングされます.これはかなり静的な情報で、簡単にキャッシュできます.
各書き込み要求において、プライマリサーバはまた、64ビットの符号なし整数が増加するfile keyを生成する.書き込み要求は通常、読み取り要求よりも頻繁ではないため、1台のプライマリサーバが同時処理をうまく行うことができるはずです.
ファイルの読み書き
クライアントが書き込み要求を送信すると、プライマリサーバはファイルに戻ります(volume id,file key,file cookie,volume node url).クライアントは、ボリュームノードに連絡し、ファイルの内容を送信します.
クライアントが(volume id,file key,file cookie)に基づいてファイルを読み込む必要がある場合、ボリュームidを使用してプライマリサーバ(volume node url,volume node public url)に問い合わせるか、キャッシュから取得できます.その後、クライアントはコンテンツを取得したり、WebページにURLを表示してブラウザにコンテンツを取得させたりすることができます.
ストレージ・サイズ
現在のインプリメンテーションでは、各ボリュームは8 x 2^32バイト(32 GiB)であってもよい.これは、コンテンツを8バイトに揃えるためです.2行のコードを変更することで、64 Gまたは128 G以上に簡単に追加できます.代わりに、位置合わせによる無駄な充填スペースがあります.
2^32巻まで可能です.従って、システム全体のサイズは、8 x 2^32バイトx 2^32=8 x 4 GiB x 4 Gi=128 EiB(2^67バイトまたは128 exbibytes)である.
個々のファイルサイズはボリュームサイズに制限されています.
使用例
この例では、クラスタを簡単に構築します.クラスタ計画は次のとおりです.
Master Server : 192.168.0.193
Volmue Server: 192.168.0.191 192.168.0.193 192.168.0.195 192.168.0.196
Master Serverの起動

./weed master -ip=192.168.0.193

Volume Serverの起動

./weed volume -dir=/weedfs_data  -mserver=192.168.0.193:9333 -port=8083 -ip=`hostname -i`

ファイルの書き込み
ファイルをアップロードするには、まず、/dir/assignにHTTP POST、PUTまたはGET要求を送信してfidおよびボリュームサーバurlを取得します.

> curl -X POST http://192.168.0.193:9333/dir/assign
{"fid":"8,081df3da0dce77","url":"192.168.0.196:8083","publicUrl":"192.168.0.196:8083","count":1}

次に、ファイルの内容を保存するには、応答中のurl+'/'+fidにHTTPマルチパーツPUTまたはPOSTリクエストを送信します.

> curl -X PUT -F file=@./test.log http://192.168.0.196:8083/8,081df3da0dce77
{"name":"test.log","size":8}

ファイルを更新するには、新しいファイル内容を使用してPUTまたはPOSTリクエストを再送信するだけです.
ファイルを削除するには、HTTP DELETE要求を同じURL+'/'+fid URLに送信するだけです.

> curl -X DELETE http://192.168.0.196:8083/8,081df3da0dce77

ファイル読み込み
まずファイルのvolumeIdでvolume serverを検索します

> curl -X get http://192.168.0.193:9333/dir/lookup?volumeId=8
{"volumeId":"8","locations":[{"url":"192.168.0.196:8083","publicUrl":"192.168.0.196:8083"}]}

パブリックURLを使用してボリュームサーバから読み込むことができます

http://192.168.0.196:8083/8,081df3da0dce77 

パフォーマンス
weedfs自動コマンドを使用して構築された4つのデータノードのクラスタに対して簡単な性能テストを行い、50万サイズ50 KBのファイルを使用して読み書き操作を行い、テストコマンドと結果は以下の通りである.
書き込み中に194ノードのディスクがいっぱいになったため、書き込み要求の一部が失敗したことはほとんどありませんが、テスト結果には影響しません.

./weed benchmark -size=51200 -n=500000 -server=192.168.0.193:9333
------------ Writing Benchmark ----------
Concurrency Level:      16
Time taken for tests:   278.368 seconds
Complete requests:      499520
Failed requests:        480
Total transferred:      25591146326 bytes
Requests per second:    1794.46 [#/sec]
Transfer rate:          89778.15 [Kbytes/sec]

Connection Times (ms)
              min      avg        max      std
Total:        0.7      8.8       18660.8      106.4

Percentage of the requests served within a certain time (ms)
   50%      7.1 ms
   66%      8.4 ms
   75%      9.3 ms
   80%     10.0 ms
   90%     12.9 ms
   95%     16.3 ms
   98%     21.0 ms
   99%     24.6 ms
  100%    18660.8 ms
------------ Randomly Reading Benchmark ----------
Concurrency Level:      16
Time taken for tests:   196.642 seconds
Complete requests:      500000
Failed requests:        0
Total transferred:      25615722837 bytes
Requests per second:    2542.69 [#/sec]
Transfer rate:          127212.71 [Kbytes/sec]

Connection Times (ms)
              min      avg        max      std
Total:        0.2      6.2       219.8      4.2

Percentage of the requests served within a certain time (ms)
   50%      5.8 ms
   66%      7.5 ms
   75%      8.2 ms
   80%      8.7 ms
   90%     10.7 ms
   95%     14.0 ms
   98%     16.8 ms
   99%     18.6 ms
  100%    219.8 ms

その他の機能

は、データコピーを使用するかどうか、およびコピーのレベル

を選択することができる.

master servers失敗自動ドリフト-点故障を根絶する

ファイルのmimeタイプに応じて自動的にgzip圧縮(linuxファイルのmimeタイプ、file--mime-typeを表示)

削除および更新操作後の圧縮による自動ディスク領域回収

を実現する.

クラスタ内のサーバ間には、異なるディスク領域、ファイルシステム、オペレーティングシステム

が存在することができる.

サービスの追加/削除は、データの再バランス

を招くことはありません.

選択修復jpegピクチャの方向以下の特性はまだ検討されていないので、後で追加しましょう

Optional filer server provides "normal"directories and files via http

Support Etag, Accept-Range, Last-Modified, etc.

Support in-memory/leveldb/boltdb/btree mode tuning for memory/performance balance.