ディレクトリにはいくつのファイルを置くことができますか?


561

1つのディレクトリにいくつのファイルを保持するかは重要ですか?もしそうなら、ディレクトリ内のファイルの数は多すぎますが、ファイルが多すぎるとどのような影響がありますか?(これはLinuxサーバー上にあります。)

背景:フォトアルバムのウェブサイトを持っています。アップロードしたすべての画像の名前が8桁の16進数のID(a58f375c.jpgなど)に変更されます。これは、ファイル名の競合を回避するためです(たとえば、「IMG0001.JPG」ファイルが多数アップロードされている場合)。元のファイル名と有用なメタデータはデータベースに保存されます。現在、imagesディレクトリには約1500個のファイルがあります。これにより、ディレクトリ内のファイルの一覧表示(FTPまたはSSHクライアント経由)に数秒かかります。しかし、それ以外の効果があるとは思えません。特に、画像ファイルがユーザーに提供される速さには何の影響もないようです。

私は16個のサブディレクトリを作成して画像の数を減らすことを考えました:0-9とaf。次に、ファイル名の最初の16進数が何であるかに基づいて、イメージをサブディレクトリに移動します。しかし、FTP / SSHを介して時々ディレクトリをリストすることを除いて、そうする理由があるかどうかはわかりません。

回答:


736

FAT32

  • 最大ファイル数:268,173,300
  • ディレクトリあたりの最大ファイル数:2 16  - -1(65,535)
  • 最大ファイルサイズ:2 GiB-1(LFSなし)、4 GiB-1(あり)

NTFS

  • 最大ファイル数:2 32-1  (4,294,967,295)
  • 最大ファイルサイズ
    • インプリメンテーション:2 44  - 2 6バイト(16のTiB - 64 KiBの)
    • 理論:2 64  - 2 6バイト(16 EIB - 64 KiBの)
  • 最大ボリュームサイズ
    • 実装:2 32-1  クラスター(256 TiB-64 KiB)
    • 理論:2つの64  - 1クラスタ(1 YiB - 64 KiBの)

ext2

  • 最大ファイル数:10 18
  • ディレクトリあたりの最大ファイル数:〜1.3×10 20(10,000を超えるパフォーマンスの問題)
  • 最大ファイルサイズ
    • 16 GiB(1 KiBのブロックサイズ)
    • 256 GiB(2 KiBのブロックサイズ)
    • 2 TiB(4 KiBのブロックサイズ)
    • 2 TiB(8 KiBのブロックサイズ)
  • 最大ボリュームサイズ
    • 4 TiB(ブロックサイズは1 KiB)
    • 8 TiB(2 KiBのブロックサイズ)
    • 16 TiB(4 KiBのブロックサイズ)
    • 32 TiB(ブロックサイズ8 KiB)

ext3

  • 最大ファイル数:min(volumeSize / 2 13、numberOfBlocks )
  • 最大ファイルサイズ:ext2と同じ
  • 最大ボリュームサイズ:ext2と同じ

ext4

  • 最大ファイル数:2 32-1  (4,294,967,295)
  • ディレクトリあたりの最大ファイル数:無制限
  • 最大ファイルサイズ:2 44  - 1バイト(16のTiB - 1)
  • 最大ボリュームサイズ:2 48  - 1バイト(256のTiB - 1)

24
これらはディレクトリではなく、パーティション全体の最大ファイル数であると思います。したがって、方法に関係なく同じ数のファイルが存在するため(ディレクトリをファイルとしてカウントしない限り)、この情報は問題に関してあまり役に立ちません。
ストレッジャー2009年

19
今は2012年なので、ext4にはサブディレクトリの数に関する制限がないことを明確にする時がきたと思います。また、最大ファイルサイズは16 TBに増加しました。さらに、ファイルシステムの全体的なサイズは最大1 EB = 1,048,576 TBになる場合があります。
devsnd 2012年

7
どうやら、ext3もディレクトリごとに60,000ファイル(またはディレクトリまたはリンク)の制限があります。私はこれについて難しい方法を見つけました。
スタック型の2014年

8
古い答えですが、わかっています…しかし、EXT4ファイルの最大数:2³²-1(4,294,967,295)およびディレクトリごとの最大ファイル数:無制限 2³²-1!=「無制限」なので、本当に混乱しています。今コーヒーが必要だと思います。それにもかかわらず+1
e-sushi

11
ハードファイルシステムの制限は、「質問に答えていない、私が1つのディレクトリに保つどのように多くのファイルが重要ですか?
Etki

191

1つのext3ディレクトリに800万以上のファイルがありました。readdir()によって使用されるlibc findlsおよびこのスレッドで説明されている他のほとんどのメソッドは、大きなディレクトリをリストします。

この場合の理由lsfind遅いのはreaddir()、一度に32Kのディレクトリエントリしか読み取らないため、低速のディスクでは、ディレクトリを一覧表示するために多くの読み取りが必要になるためです。この速度の問題には解決策があります。私はそれについてかなり詳細な記事を書きました:http : //www.olark.com/spw/2011/08/you-can-list-a-directory-with-8-million-files-but-not-with- ls /

重要なポイントは次のとおりです。バッファを指定できるように、libcに基づくものではなく、getdents()直接使用してください。http://www.kernel.org/doc/man-pages/online/pages/man2/getdents.2.html readdir()ディスクからディレクトリエントリを読み取るときのサイズ。


6
おもしろい!1つのディレクトリに800万のファイルがあった状況を確認できますか?(笑)
Aᴄʜᴇʀᴏɴғᴀɪʟ

私も同じでした。テーブルのblob列を移行しました。各blob列はファイルとしてエクスポートしました。それは約800万ファイルです:)
スパイク

65

私には88,914個のファイルがあるディレクトリがあります。自分と同じように、これはサムネイルの保存とLinuxサーバーで使用されます。

FTPまたはphp関数を介してリストされたファイルは低速ですが、ファイルを表示するとパフォーマンスが低下します。たとえば、www.website.com / thumbdir / gh3hg4h2b4h234b3h2.jpgの待機時間は200〜400 msです。別のサイトとの比較として、ディレクトリに約100個のファイルがある場合、画像は約40ms待機した後に表示されます。

ほとんどの人がディレクトリ検索機能の実行方法を書いたばかりなので、この回答を示しました。サムフォルダーでは使用せず、ファイルを静的に表示するだけですが、実際にファイルを使用する方法のパフォーマンスに関心があります。 。


6
これが唯一の有用な答えです。同様の経験をしました。バックアップに関する問題を減らすために、ファイル数は1.000ファイルに制限されています(あまりに多くのディレクトリが遅くなります)。
mgutt

1
noatimeオプションと同様でドライブをマウントするために役立つことができます:howtoforge.com/...をして、この、あまりにも読み:serverfault.com/questions/354017/...
mgutt

2
どのファイルシステムを使用しているのですか?たとえば、XFSは、目立った速度低下なしに、ディレクトリ内の100,000個のファイルを簡単に処理できる必要があります。
イーサン

1
他のほとんどの意見と矛盾して、私はこの答えを確認したいと思います。ソーシャルネットワークのウェブサイトには何十万もの画像があります。パフォーマンスを向上させるために、100(またはいくつかのファイルでは1000)のサブディレクトリを用意し、それらにファイルを配布する必要がありました(Linux + Apacheのext3)。
wmac 14

57

Linuxサーバーで使用されている特定のファイルシステムによって多少異なります。現在、デフォルトはdir_indexを指定したext3であり、これにより大きなディレクトリの検索が非常に高速になります。

したがって、速度は問題ではないはずです。ただし、すでに述べたもの以外は、リストに時間がかかるということです。

1つのディレクトリ内のファイルの総数には制限があります。私はそれが間違いなく32000ファイルまで機能していることを覚えているようです。


4
GnomeとKDEは大きなディレクトリをカタツムリのペースでロードします。Windowsはそのディレクトリをキャッシュするので、妥当です。私はLinuxが好きですが、kdeとgnomeは不十分に書かれています。
2010

1
そして、ext4はデフォルトでdir_indexと同等のものを持っているようです。
ファルケン教授の契約が

22
ext3の1つのディレクトリには約32Kのサブディレクトリという制限がありますが、OPは画像ファイルについて話します。Dir Indexが有効になっているext3ファイルシステムのファイルには(実用的ですか?)制限はありません。
ピーターNルイス

1
この回答は古くなっており、現在のデフォルトはext4です。
Boris

1
「Dir Indexを有効にしたext3ファイルシステムのファイルに(実用的な)制限はありません」-有効にした4TB ext4ファイルシステムのディレクトリでファイルスペースが足りなくdir_indexなりました。ディレクトリには約1700万のファイルがありました。答えはlarge_dirtune2fsでオンにすることでした。
lunixbochs

49

Linuxでは、ファイルが多すぎるディレクトリがある場合、シェルがワイルドカードを展開できない場合があることに注意してください。Linuxでホストされているフォトアルバムでこの問題が発生しました。サイズ変更されたすべての画像を1つのディレクトリに保存します。ファイルシステムは多くのファイルを処理できますが、シェルは処理できません。例:

-shell-3.00$ ls A*
-shell: /bin/ls: Argument list too long

または

-shell-3.00$ chmod 644 *jpg
-shell: /bin/chmod: Argument list too long

33
@Steve、これらの場合は、find(1)またはxargs(1)を使用してください。同じ理由で、コマンドライン展開の代わりにスクリプトでそのようなツールを使用することは良い考えです。
デイブC

3
@Steveフォルダー内のファイル数が増えるとパフォーマンスが低下しますか?それとも関係はありませんか?
Pacerier

6
これは良い点ですが、ちなみに、与えられた理由は間違っています。引数リストが長すぎないシェルのが、システムの制限のあるexec実装。シェルは通常、ワイルドカードを問題なく展開できexecます。エラーを返すのは、その多くの引数を使用した呼び出しです。
jw013

昨夜(Fedora 15)で同じエラーが発生し、ディレクトリに約〜400,000個のファイルがある "rm"(somefiles *)が発生しました。ワイルドカードを使用して「rm」できるようになるまで、「find」を使用して古いファイルをトリミングできました。
PJ Brunet 2013年

etx4上のディレクトリへの10.000.000ファイルは正常に機能します。アクセス時のパフォーマンスへの影響はそれほどありません。しかし、ワイルドカードを使用するとかなり遅くなります。ファイル名をソートするのが好きなシェルプログラムを使用するときは注意してください!:)
SimonRigét2018

25

現在、同様の問題に取り組んでいます。階層的なディレクトリ構造があり、ファイル名としてイメージIDを使用します。たとえば、次の画像id=1234567

..../45/67/1234567_<...>.jpg

最後の4桁を使用して、ファイルの移動先を決定します。

数千の画像があれば、1レベルの階層を使用できます。私たちのシステム管理者は、効率/バックアップ/彼が考えていた他の理由のために、特定のディレクトリ(ext3)にあるファイルを数千以下にすることを提案しました。


1
これはかなり良い解決策です。2桁の内訳に固執する場合、ファイルまでのディレクトリのすべてのレベルに最大100のエントリがあり、最下部のディレクトリには1つのファイルしかありません。
RobKohr、2016年


21

それだけの価値があるので、ext4ファイルシステムに1,000,000個のファイルを含むディレクトリを作成し、Webサーバーを介してそれらのファイルにランダムにアクセスしました。私はそこに(たとえば)10個のファイルしか持っていないユーザーにアクセスすることに特別な気づきはありませんでした。

これは、数年前の私の経験とは根本的に異なりntfsます。


どんなファイル?テキストまたは画像?私はext4を使用していて、ワードプレスの下の単一のディレクトリに80000の画像をインポートする必要があり、それが問題ないかどうか知りたい
Yvon Huynh

1
@YvonHuynh:ファイルの種類はまったく関係ありません。ファイルを一覧表示/追跡するディレクトリのオーバーヘッドは同じです。
TJクラウダー2017

14

私が遭遇した最大の問題は、32ビットシステムです。特定の数を渡すと、「ls」などのツールが機能しなくなります。

そのバリアを通過した後、そのディレクトリで何かをしようとすると、大きな問題になります。


9

同じ問題が発生しています。ext4のUbuntuサーバーに数百万のファイルを保存しようとしています。自分のベンチマークの実行を終了しました。フラットディレクトリは、使用方法がシンプルでありながらパフォーマンスが優れていることがわかりました。

基準

記事を書いた。


ソリューションへのリンクを歓迎しますが、それがなくても回答が役に立つことを確認してください。リンクの周りにコンテキストを追加して、他のユーザーがそれが何であるか、なぜそこにあるのかを理解し、ページの最も関連性の高い部分を引用してくださいターゲットページが利用できない場合にリンクし直します。リンクに過ぎない回答は削除される場合があります。
サミュエルLiew

1
面白い。10,000ファイルでも、パフォーマンスが非常に急速に低下し、使用できなくなることがわかりました。最適なパフォーマンスを実現するために、ファイルを各レベルで約100のサブディレクトリに分割することにしました。この話の教訓は、自分のシステムで自分の要件を常に自分でベンチマークすることだと思います。
Joshua Pinter、

7

ディレクトリパーティションスキームの実装にかかる時間が最小限であれば、私はそれを支持します。コンソールを介して10000ファイルのディレクトリを操作することを含む問題を初めてデバッグする必要があるときは、理解できるでしょう。

例として、F-Spotは写真ファイルをYYYY \ MM \ DD \ filename.extとして保存します。これは、〜20000の写真コレクションを手動で操作するときに私が処理しなければならなかった最大のディレクトリが約800ファイルであることを意味します。これにより、サードパーティのアプリケーションからファイルをより簡単に参照できるようになります。あなたのソフトウェアがあなたのソフトウェアのファイルにアクセスする唯一のものであることを決して仮定しないでください。


6
一括インポートは特定の日付にファイルをクラスター化する可能性があるため、日付によるパーティション分割を宣伝します。
最大の

良い点。パーティション分割スキームを選択する前に、必ずユースケースを検討する必要があります。比較的幅広い分布で何日も写真をインポートすることがあり、Fスポットの日付以外の写真を操作したい場合は、写真を見つける最も簡単な方法です。
Sparr、2009年

7

それは絶対にファイルシステムに依存します。最近のファイルシステムの多くは、まともなデータ構造を使用してディレクトリの内容を格納していますが、古いファイルシステムは多くの場合、エントリをリストに追加しただけなので、ファイルの取得はO(n)操作でした。

ファイルシステムが正しく機能している場合でも、ディレクトリの内容を一覧表示するプログラムが失敗してO(n ^ 2)の並べ替えを行うことは絶対に可能です。そのため、安全のため、常に1ファイルあたりのファイル数を制限します。ディレクトリは500以下にしてください。


7

実際に使用するファイルシステムといくつかのフラグに依存します。

たとえば、ext3は何千ものファイルをことができます。しかし、数千の後、それは非常に遅くなりました。ほとんどの場合、ディレクトリをリストするときだけでなく、単一のファイルを開くときもそうです。数年前、「htree」オプションが追加され、ファイル名を指定してiノードを取得するために必要な時間が大幅に短縮されました。

個人的に、私はサブディレクトリを使用して、ほとんどのレベルを1000項目程度に抑えています。あなたの場合、IDの最後の2桁の16進数で256のディレクトリを作成します。最初の桁ではなく最後の桁を使用して、負荷を分散します。


6
ファイル名が完全にランダムである場合、どの桁が使用されたかは関係ありません。
ストレッジャー、2009年

実際、これらのファイル名はランダムに生成されます。
キップ

2
または、ファイル名のSHA-1ダイジェストの最初のNバイトを使用します。
ガウィ2015年

6

実際、ext3にはディレクトリサイズの制限があり、ファイルシステムのブロックサイズによって異なります。ディレクトリごとの「最大数」のファイルはありませんが、ディレクトリごとの「ファイルエントリの保存に使用される最大ブロック数」はありません。具体的には、ディレクトリ自体のサイズが高さ3のbツリーを超えて大きくなることはなく、ツリーのファンアウトはブロックサイズによって異なります。詳細については、このリンクを参照してください。

https://www.mail-archive.com/cwelug@googlegroups.com/msg01944.html

私は最近、2Kブロックでフォーマットされたファイルシステムでこれに噛まれました。これはwarning: ext3_dx_add_entry: Directory index full!、別のext3ファイルシステムからコピーしているときに、ディレクトリフルのカーネルメッセージを不可解に受け取っていました。私の場合、わずか480,000ファイルのディレクトリを宛先にコピーできませんでした。


5

問題は、ファイルをどうするかです。

Windowsでは、2k個を超えるファイルを含むディレクトリは、エクスプローラーで開くのが遅くなる傾向があります。それらがすべて画像ファイルの場合、1Kを超えるとサムネイルビューで開くのが非常に遅くなる傾向があります。

かつて、システムが課した制限は32,767でした。今はもっと高いですが、それでもほとんどの状況で一度に処理するにはファイルが多すぎます。


5

上記の回答のほとんどが示していないのは、元の質問に対する「1つのサイズですべてに対応する」という回答がないことです。

今日の環境には、さまざまなハードウェアとソフトウェアの大規模な集まりがあります。32ビットの場合もあれば、64ビットの場合もあれば、最先端である場合もあります。これに追加されるのは、さまざまな新旧のハードウェア、新旧のOS、さまざまなベンダー(Windows、Unix、Appleなど)、および無数のユーティリティとサーバーです。ハードウェアが改善され、ソフトウェアが64ビット互換に変換されるにつれ、この非常に大きく複雑な世界のすべての要素が急速な変化のペースでうまく機能するようになるには、かなりの遅延が必然的にありました。

IMHO問題を解決する方法は1つではありません。解決策は、可能性を調査し、試行錯誤によって特定のニーズに最適なものを見つけることです。各ユーザーは、Cookieカッターのアプローチを使用するのではなく、システムに何が機能するかを決定する必要があります。

たとえば、非常に大きなファイルがいくつかあるメディアサーバーがあります。結果は、3 TBのドライブを埋める約400ファイルのみです。iノードの1%のみが使用されますが、合計スペースの95%が使用されます。他の誰かが多くの小さなファイルを使用すると、スペースがいっぱいになる前にiノードが不足する可能性があります。(経験則として、ext4ファイルシステムでは、ファイル/ディレクトリごとに1つのiノードが使用されます。)理論的には、ディレクトリ内に含まれる可能性のあるファイルの総数はほぼ無限ですが、実用性は、全体的な使用法が現実的な単位ではなく、ファイルシステムの機能だけです。

上記のすべての異なる答えが、進歩への克服できない障壁を提示するのではなく、思考と問題解決を促進したことを願っています。


4

出力で大量のファイルを作成していたプログラムを実行したことを思い出します。ファイルはディレクトリごとに30000でソートされました。生成された出力を再利用する必要があったときに、読み取りの問題があったことを思い出しません。これは32ビットUbuntu Linuxラップトップ上にあり、Nautilusでさえ数秒後ではあるがディレクトリの内容を表示していました。

ext3ファイルシステム:64ビットシステムの同様のコードは、ディレクトリごとに64000ファイルを適切に処理しました。


4

「ファイルシステムに依存」
一部のユーザーは、パフォーマンスへの影響は使用するファイルシステムに依存すると述べました。もちろん。EXT3のようなファイルシステムは非常に遅くなる可能性があります。しかし、あなたがEXT4またはXFSを使用している場合でも、あなたはを通してフォルダを一覧表示することを防ぐことができないlsか、findまたはFTPなどの外部接続を介してすることは遅く遅くなります。

解決
私は@armandinoと同じ方法を好みます。そのために、この小さな関数をPHPで使用して、IDをファイルパスに変換し、ディレクトリごとに1000個のファイルを作成します。

function dynamic_path($int) {
    // 1000 = 1000 files per dir
    // 10000 = 10000 files per dir
    // 2 = 100 dirs per dir
    // 3 = 1000 dirs per dir
    return implode('/', str_split(intval($int / 1000), 2)) . '/';
}

または、英数字を使用したい場合は、2番目のバージョンを使用できます。

function dynamic_path2($str) {
    // 26 alpha + 10 num + 3 special chars (._-) = 39 combinations
    // -1 = 39^2 = 1521 files per dir
    // -2 = 39^3 = 59319 files per dir (if every combination exists)
    $left = substr($str, 0, -1);
    return implode('/', str_split($left ? $left : $str[0], 2)) . '/';
}

結果:

<?php
$files = explode(',', '1.jpg,12.jpg,123.jpg,999.jpg,1000.jpg,1234.jpg,1999.jpg,2000.jpg,12345.jpg,123456.jpg,1234567.jpg,12345678.jpg,123456789.jpg');
foreach ($files as $file) {
    echo dynamic_path(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
1/123.jpg
1/999.jpg
1/1000.jpg
2/1234.jpg
2/1999.jpg
2/2000.jpg
13/12345.jpg
12/4/123456.jpg
12/35/1234567.jpg
12/34/6/12345678.jpg
12/34/57/123456789.jpg

<?php
$files = array_merge($files, explode(',', 'a.jpg,b.jpg,ab.jpg,abc.jpg,ddd.jpg,af_ff.jpg,abcd.jpg,akkk.jpg,bf.ff.jpg,abc-de.jpg,abcdef.jpg,abcdefg.jpg,abcdefgh.jpg,abcdefghi.jpg'));
foreach ($files as $file) {
    echo dynamic_path2(basename($file, '.jpg')) . $file . PHP_EOL;
}
?>

1/1.jpg
1/12.jpg
12/123.jpg
99/999.jpg
10/0/1000.jpg
12/3/1234.jpg
19/9/1999.jpg
20/0/2000.jpg
12/34/12345.jpg
12/34/5/123456.jpg
12/34/56/1234567.jpg
12/34/56/7/12345678.jpg
12/34/56/78/123456789.jpg
a/a.jpg
b/b.jpg
a/ab.jpg
ab/abc.jpg
dd/ddd.jpg
af/_f/af_ff.jpg
ab/c/abcd.jpg
ak/k/akkk.jpg
bf/.f/bf.ff.jpg
ab/c-/d/abc-de.jpg
ab/cd/e/abcdef.jpg
ab/cd/ef/abcdefg.jpg
ab/cd/ef/g/abcdefgh.jpg
ab/cd/ef/gh/abcdefghi.jpg

$int-version を見るとわかるように、すべてのフォルダには、最大1000個のファイルと、最大99個のディレクトリが含まれ、1000個のファイルと99個のディレクトリが含まれています...

ただし、多くのディレクトリで同じパフォーマンスの問題が発生することを忘れないでください。

最後に、全体でファイルの量を減らす方法を検討する必要があります。ターゲットに応じて、CSSスプライトを使用して、アバター、アイコン、スマイリーなどの複数の小さな画像を組み合わせることができます。また、多くの小さな非メディアファイルを使用する場合は、JSON形式などでそれらを組み合わせることを検討してください。私の場合、私は何千ものミニキャッシュを持っていて、最後にそれらを10個のパックに組み合わせることにしました。


3

数が多すぎるという質問には完全には答えられませんが、長期的な問題を解決するためのアイデアは、元のファイルのメタデータを保存するだけでなく、ディスクに保存されているフォルダーも保存することです-正規化そのメタデータを取り出します。フォルダーがパフォーマンス、美観、またはその他の理由で満足できる制限を超えたら、2番目のフォルダーを作成し、そこにファイルのドロップを開始します...


3

私は同様の問題に遭遇しました。10,000以上のファイルが含まれるディレクトリにアクセスしようとしました。ファイルリストを作成し、任意のファイルに対して任意のタイプのコマンドを実行するには、時間がかかりすぎていました。

私はこれを自分で行うために小さなphpスクリプトを考え、それがブラウザーでタイムアウトしないようにする方法を考え出そうとしました。

以下は、問題を解決するために私が書いたphpスクリプトです。

FTPにはファイルが多すぎるディレクトリ内のファイルの一覧表示

それが誰かを助ける方法


1

答えではなく、ほんの一部の提案です。

より適切なFS(ファイルシステム)を選択します。歴史的な観点から、すべての問題は賢明であり、かつて何十年にもわたって進化するFSの中心であった。より近代的なFSが問題をより適切にサポートすることを意味します。まず、FSリストから最終的な目的に基づいて比較決定表を作成します。

あなたのパラダイムを変える時がきたと思います。だから私は個人的に分散システム対応のFSを使用することをお勧めしますます。これは、サイズ、ファイル数などに関して制限がないことを意味します。それ以外の場合、遅かれ早かれ、予期しない新しい問題に挑戦します。

確実に機能するかどうかはわかりませんが、実験に触れない場合は、現在のファイルシステムでAUFSを試してみてください。複数のフォルダを単一の仮想フォルダとして模倣する機能があると思います。

ハードウェアの制限を克服するには、RAID-0を使用できます。


1

OSの制限を超えない限り、「多すぎる」という1つの図はありません。ただし、OSに関係なく、ディレクトリ内のファイルが多いほど、個々のファイルへのアクセスにかかる時間が長くなり、ほとんどのOSでは、パフォーマンスが非線形になるため、10,000から1つのファイルを見つけるには、10倍以上長い時間がかかります。その後、1,000のファイルを検索します。

ディレクトリに多数のファイルがあることに関連する二次的な問題には、ワイルドカード拡張の失敗があります。リスクを軽減するために、アップロードの日付、またはその他のいくつかの有用なメタデータでディレクトリを並べることを検討してください。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.