Web アプリケーションを構築する際、データベース エントリに関連付けられたファイルがよくあります。たとえば、userテーブルがあり、各カテゴリにはavatar関連する画像へのパスを保持するフィールドがあります。
ファイル名に競合がないことを確認するには、次のいずれかを実行できます。
ID.jpg。パスは次のようになります/user-avatars/ID.jpg/user-avatars/ID/original_filename.jpgここで、ID はusersの一意の ID 番号です
どちらも、アプリケーション ロジックの観点からは完全に有効です。
しかし、ファイルシステムのパフォーマンスの観点からは、どちらが優れているでしょうか? エントリの数categoryが非常に多くなる可能性があることに留意する必要があります (数百万)。
ディレクトリが保持できるサブディレクトリの数に制限はありますか?
ファイル システムによって異なりますが、ext3 のような単純なものについて話していて、分散ファイル システムを実行していないと仮定します (分散ファイル システムの一部はこれが得意です)。一般に、ファイル システムは、エントリがディレクトリであるかファイルであるかに関係なく、1 つのディレクトリ内の特定の数のエントリでパフォーマンスが低下します。そのため、イメージごとに 1 つのディレクトリを作成する場合でも、ルート ディレクトリに 1 つのイメージを作成する場合でも、スケーリングの問題が発生します。この回答を見ると：
ディレクトリ内のファイル数が多すぎます (Windows および Linux)。
ext3 は、ディレクトリ内の約 32K エントリで制限に達することがわかります。これは、提案しているよりもはるかに少ないです。
思いつきで、/user-avatars/1/2/12345/original_filename.jpg のようなマルチレベルのディレクトリ ツリーに基本的なシャーディングを行うことをお勧めします。(または、あなたの ID のタイプに適したものですが、私はあなたの質問を数値 ID に関するものと解釈しています。) これを行うと、後でストレージ クラスター全体に分散することを決定したときに、ディレクトリを分散できるため、作業が楽になります。その周り。
1 つの親ディレクトリにある何百万ものエントリ (ファイルまたはディレクトリ) は、どのファイルシステムでも処理するのが困難です。最新のファイル システムでは、必要なファイルをすばやく検索するために並べ替えやさまざまなツリー アルゴリズムが使用されていますが、ファイル マネージャーがディレクトリの内容を読み取る必要があるため、Windows エクスプローラー、Midnight Commander、またはその他のファイル マネージャーを使用してフォルダーに移動することさえ複雑になります。同じことがファイル検索にも当てはまります。したがって、これにはサブディレクトリが優先されます。
ただし、すべてのファイルが1つのディレクトリにある場合、少なくともNTFSでサブディレクトリに分割されている場合よりも、特定のファイルへのアクセスが少し速くなることに注意する必要があります(400Kファイルで数回測定しました)。
本当にファイルを使用したい場合は、ファイルをいくつかのサブディレクトリに分割して、制限に達しないようにすることをお勧めします。たとえば、ID が 123456 の場合、/12/34/56.jpg に入れることができます。
ただし、データベースを既に使用しているため、このデータを保存するためにデータベースを使用することをお勧めします。画像データと ID を同じテーブルに保存でき、パーミッションが正しく設定されていることを確認するなど、ファイルを扱う面倒な作業について心配する必要はありません。