レプリケーションを使用する数百万のファイル用のLinuxファイルシステムまたはCDN
このシナリオの解決策を教えてください：
- 1つのディレクトリにある数百万のファイル（ "img/8898f6152a0ecd7997a68631768fb72e9ac2efe1_1.jpg"）
- 平均で約80kのファイルサイズ
- 90％のランダム読み取りアクセス
- 他のサーバーへのバックアップ（レプリケーション）（5分ごとまたはすぐに）
- 画像のメタデータがデータベースに保存されます
ファイル数が200万を超えると、ランダムアクセス時間が遅くなるという問題が発生しました。ファイルシステムはext3で、noatimeおよびdir_indexオプションがありますが、「ls」や「find」などのコマンドを使用する必要はありません。
私が可能だと思う解決策：
- ext3のままで、ディレクトリツリー構造を「img/889/8f6/152 /a0ecd7997a68631768fb72e9ac2efe1_1.jpg」に変換するだけです。
- 他のファイルシステム（ReiserFS、XFS、EXT4など）に移行します
- 分散ファイルシステムを使用したストレージエンジンのセットアップ（例を挙げてください）
- または多分他...
1または2を選択した場合、どのように複製しますか？ rsyncは、ext3ファイルシステム上のこのような大量のデータを処理できません。
私たちにとって最善の解決策はAmazonS3を使用することですが、これは私たちのトラフィックでは高すぎます...多分あなたはいくつかのアナログ（安いCDNまたはオープンソースプロジェクト）をお勧めします
1つのディレクトリにある何百万ものファイルは設計が悪く、遅くなります。それらをエントリ数の少ないディレクトリに分割します。
見てください https://unix.stackexchange.com/questions/3733/number-of-files-per-directory
RAIDやSSDを使用します。これ自体では遅いアクセス時間を解決することはできませんが、複数のディレクトリを導入し、ディレクトリあたりのファイル数を1桁または2桁減らすと、ホットスポットを防ぐのに役立ちます。
XFSを検討してください。特に、複数のドライブと複数のディレクトリを使用する場合は、優れた利点が得られる可能性があります（使用するオプションについては、たとえば this スレッドを参照してください。mdRAIDでのXFSに関するヒントをいくつか示します） 。
個人的に私は：
- 現在のFSに固執します。提案したようにそれらをディレクトリに分割します。必要に応じて、単一のディレクトリとして表示することもできます。
mod_rewrite（これはCDNタイプのアプリケーションだと思います） - 複製が必要な変更をログに記録します。毎日/毎時など、同期する必要があるたびに、コピーする必要のあるファイルを作成するのは、ログで
diffを実行するのと同じくらい簡単です（つまり、常にログを同期して最初に同期しますが、それらを置き換える前に差分を取り、他にコピーが必要なものを計算します）。