私の PHP プロジェクトは何千もの画像を使用し、それぞれのストレージ名に必要な数字は 1 つだけです。
私の最初のアイデアは、すべての写真を単一のディレクトリに置き、ファイルに「0.jpg」、「1.jpg」、「2.jpg」、そして「4294967295.jpg」という名前を付けることでした。
ディレクトリ ツリー構造を作成し、ファイルに「429 / 496 / 7295.jpg」のような名前を付けた方が、パフォーマンスが向上しますか?
答えが「はい」の場合、フォローアップの質問は次のようになります: 深さのレベルごとのサブディレクトリまたはファイルの最適な量は? そして、選択したファイルシステムはこれにどのような影響を与えますか?
各ファイルには、UNSIGNED LONGINT ID 番号を持つ対応する MySQL エントリがあります。
ありがとうございました。
従来の知恵は「データベースを使用する」ですが、ファイルシステムを使用することは、画像のような大きなオブジェクトの合理的な計画です。
一部のファイルシステムでは、ディレクトリ エントリの数に制限があります。一部のファイルシステムには、ファイル名検索用のデータ構造がまったくなく、ディレクトリの線形スキャンのみが実行されます。
あなたが議論しているような最適化は、特定の環境プロファイルに制限されています。あなたのアプリケーションが将来どのようなハードウェアで実行されるか、今すぐにでも知っていますか? ファイルシステムに負担をかけず、適切な階層ディレクトリ構造を作成するのは良い考えでしょうか? これを行うと、どのファイルシステムまたはストレージ サーバーでも問題なく動作します。
使用されているファイルシステムによって異なります。ext {2,3,4}には、作成時に設定できるdir_indexオプションがあり、1つのディレクトリに数千または数百万ものファイルをかなり高速に保存できます。
btrfsはまだ本番環境に対応していませんが、非常に基本的なレベルでこのアイデアを暗黙的にサポートしています。
ただし、dir_indexまたは他のほとんどのUnixファイルシステムを使用せずにextシリーズを使用している場合は、複数のレベルのディレクトリを持つという、より複雑なスキームを使用する必要があります。できればそれを避けることをお勧めします。それは、ファイルシステムがあなたのために合理的に処理すべきものに多くの余分な複雑さを追加するだけです。
より複雑なスキームを使用する場合は、数値を16進数でエンコードし、各レベルに256個のファイル/ディレクトリを用意することをお勧めします。各ディレクトリ内の多数のファイルを処理するように設計されていないファイルシステムは、通常、線形スキャンを実行します。目標は、Bツリータイプの構造を自分で近似することです。各レベルで2桁の16進数を使用すると、ディレクトリをエンコードする一般的な手段を使用して、レベルごとに約半分の4kiB（一般的なサイズ）のディスクブロックが得られます。これは、23を基数または24を基数で数値をエンコードするような非常に複雑なスキームなしで得られるものとほぼ同じです。
1 つのディレクトリに数千のファイルがあると、処理速度が大幅に低下します。安全な数は、ディレクトリあたり最大 1024 ファイル、512 ファイルまでだと思います。
もちろん、答えは次のとおりです。
特に、使用するファイル システムによって異なります。たとえば、ext2およびext3ファイル システムには、ディレクトリあたりのファイル数に制限があります。これらのファイル システムでは、すべての画像を 1 つのディレクトリに格納することはできません。
ファイルシステム以外の何かを調べるかもしれません。私が働いている会社では、大量の資料を保存する必要があったため、ファイル ベースのストレージからApache Jackrabbitで実行されるデータベース ベースのストレージに移行しました。