ご挨拶、
さまざまな写真のWebサイトからの画像を処理するスクリプトをいくつか書いています。現在、私はこのすべてのデータを同じディレクトリ内の個々のテキストファイルに保存しています。
ディレクトリはWebアクセス可能です。エンドユーザーは、ユーザーが必要とするファイルへのパスを返すWebサービスを呼び出します。
これらのすべてのファイルを同じディレクトリに置くことで、どの段階でパフォーマンスに影響が出るのでしょうか？（もしあれば）
回答:
パフォーマンスは、使用しているファイルシステムによって異なります。
EXT3：物理的な制限は32,000ファイルですが、perfは数千のファイルの後で苦しみます。
EXT4：理論的には無限
ReiserFS、XFS、JFS、BTRFS：これらは、より現代的で多くのファイルを処理するように設計されているため、ディレクトリ内の多くのファイルに適しています（他は、HDDがGBではなくMBで測定された時代に設計されました） 。多くのファイル（ext4を含む）のパフォーマンスは、両方とも目的のファイルを取得するためにバイナリ検索タイプのアルゴリズムを使用している（他のファイルはより線形のファイルを使用している）ため、はるかに優れています。
Webサーバーで提供するために画像を保存し、EXT3の1つのディレクトリに300,000を超える画像があります。パフォーマンスの問題はありません。これを設定する前に、ディレクトリ内の50万イメージでテストを行い、名前でファイルにランダムにアクセスしました。
唯一の欠点は、新しいサーバーを2番目のサーバーと同期するために、rsyncディレクトリ全体で実行する必要があることです。また、最新の1,000程度を含むサブディレクトリを同期するように指示することができません。
フォルダー内のファイルの量は理論的には無制限です。ただし、OSが特定のフォルダーにアクセスしてファイルを検索するたびに、そのフォルダー内のすべてのファイルを処理する必要があります。500個未満のファイルでは、遅延に気付かない場合があります。ただし、1つのフォルダーに数万のファイルがある場合、単純なフォルダーリストコマンド（lsまたはdir）を使用すると時間がかかりすぎる可能性があります。これらのフォルダにFTP経由でアクセスできる場合、実際には遅すぎます...
パフォーマンスの問題は、お使いのOSではなく、システムプロセッサの速度、ディスク容量、メモリに依存します。その数のファイルがある場合は、それらを1つのアーカイブに結合し、大量のデータを保持するように最適化されたアーカイブシステムを使用することができます。これはZIPファイルでもかまいませんが、ファイル名を主キーとしてデータベースにBLOBとして保存してください。
lsは、1000個のファイルを含むものよりも大幅に遅くなることはありません。
@skaffmanが指摘しているように、制限はオペレーティングシステムによって異なります。古いOSの制限の影響を受ける可能性があります。Solarisの古いバージョンは、ディレクトリごとに32768ファイルに制限されていたことを覚えています。
通常の解決策は、ある種のハッシュを使用することです。つまり、Cyrus imapサーバーはユーザーをアルファベットのハッシュで分割します。
/var/spool/imap/a/user/anna/
/var/spool/imap/a/user/albert/
/var/spool/imap/d/user/dan/
/var/spool/imap/e/user/ewan/
ファイルに直接アクセスしている場合、ディレクトリ内のファイルの数は速度の問題ではありません。
1つのディレクトリに作成できるファイルの数は、使用しているファイルシステムによって異なります。ディレクトリ内のすべてのファイルを一覧表示している場合や、検索、並べ替えなど、多数のファイルがある場合、これらの操作が遅くなります。
gbjbaanbは、ext3の最大ファイルサイズについての答えが間違っています。一般的に、extは一般にディスク上のファイルの数を制限します。iノードテーブルにiノードがある場合より多くのファイルを作成することはできません。彼は、多くのファイルでパフォーマンスを向上させるためにreiserfsを提案するのが正しい