当社には 500 万人のユーザーがいます。ユーザーのコードファイルを保存します。ユーザーは、Web IDE と同じように、Web IDE リスト ユーザーのファイルを編集および追加できます。readdir、file_get_contents、file_put_contents などの PHP 関数を使用して、これらの操作を実装します。MooseFSを使用しましたが、プログラムでファイルを読み取るとき、特に読み込み速度が遅いです。
そのため、ファイル システムを交換する必要があります。誰かがアドバイスをくれることを願っています。分散ファイル システムを使用する必要がある多数の小さなファイルがあります。
500 万のエントリは、リレーショナル データベースには小さいです。これらをファイル システムに保存する必要性を感じているのはなぜかと思います。
すべてのユーザーは、起動時にすべてのファイルをロードする必要がありますか? もしそうなら、私はシステムの設計について疑問に思います. その操作はO(N)、どのように設計しても問題ありません。
これらの 500 万個の小さなファイルをリレーショナル データベースまたは NoSQL データベースに配置し、各ユーザーがそれに接続して必要な特定のファイルをクエリできるようにすると、起動時にそれらを繰り返し読み込む必要がなくなります。問題が解決しました。
分散ファイルシステムにおいて、小さなファイルの操作を検討する際の最も重要な側面の 1 つは、ネットワーク遅延です。このような分散ファイルシステムのコンポーネント間では、可能な限り (0.1 ミリ秒など) 小さくする必要があります。これを実現する最善の方法は、信頼できるスイッチを使用し、すべてのマシンを同じスイッチに接続することです。
また、分散ファイルシステム (特に MooseFS) では、スケーラビリティが最も優れています。つまり、ノードが多いほど (そして計算が分散されるほど、つまり複数のマウントで同時に実行されるほど)、クラスターが高速になります。
MooseFS を使用している場合は、MooseFS 3.0 バージョンから小さなファイルの操作が改善されているため、MooseFS 3.0 をチェックしてください。「革命」を起こす必要がないため、これは今のところ簡単な方法です (アップグレードの前に、マスター サーバーの /var/lib/mfs をバックアップすることを忘れないでください。つまり、メタデータです)。MooseFS は小さなファイルをうまく処理できるので、設定に問題があるのではないでしょうか?
さらに MooseFS では (まだ小さなファイルの操作を考慮しています)、最も重要なことの 1 つは、CPU クロックを高くして (3.7 GHz など)、少数の CPU コアを使用し、Master Server の BIOS で省エネ オプションを無効にすることです (Master Server はシングルスレッドプロセス)。Chunkservers と Clients の場合は状況が異なります。これらはマルチスレッドであるため、マルチコア CPU を使用するとより良い結果が得られます。
さらに、段落 4.「仮想マシンと MooseFS」のMooseFS のベスト プラクティスで述べられているように:
[...] 仮想マシンで MooseFS コンポーネント (特にマスター サーバー) を実行することはお勧めしません。
そのため、VM で MFS を実行すると、実際には悪い結果になる可能性があります。