このような Windows フォルダー構造には何十万もの jpg 画像がありますが、それらをすばやく操作するのは非常に困難です (リスト化に時間がかかり、コピーにも時間がかかります)。構造は次のとおりです。
images/
1/
10001/
10001-a.jpg
10001-b.jpg
...
10001-j.jpg (10 images in each XXXXX folder)
10002/
10003/
...
19999/
2/
20001/
20002/
20003/
...
29999/
3/
4/
5/
6/
7/
8/
9/
現在、これらの画像の参照は少し遅くなります。各 X フォルダーには約 10,000 個のフォルダーがあり、それらを一覧表示するだけでも時間がかかるためです。
サブフォルダー/アイテムを少なくして画像を整理するより良い方法はありますか? 構造をこのように変更すると、何か効果がありますか?
images/
1/
0/
0/
0/
0/
1/
2/
3/
4/
5/
6/
7/
8/
9/
10000/ (image folder, same as path)
10000-a.jpg
10000-b.jpg
...
10000-j.jpg (10 images in each image folder)
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
1/
2/
3/
4/
5/
6/
7/
8/
9/
2/
3/
4/
5/
6/
7/
8/
9/
したがって、画像 48617-c.jpg を見つけることは、パス 4/8/6/1/7/48617/48617-c.jpg と同じになります。
フルパス番号 48617 の別のフォルダーを用意する理由は、フォルダー全体をコピーすることで、10 枚の画像バッチ全体をコピーする作業を簡素化するためです。
さて、どのフォルダーにも 11 個を超えるサブフォルダーはありませんが、分離の目的で 1 桁のフォルダーが多数追加されます。この設定により、複数のユーザーが画像を追加/コピー/削除するなど、ブラウジングと操作が高速化されるでしょうか?
答え1
Windowsは、膨大な数のファイルを扱うフォルダレイアウトに関しては少し特殊です。特に画像はWindowsエクスプローラーが特別扱いするためです。とはいえ、混乱を避けるために従うべきガイドラインがいくつかあります。あまりにも手を離れて：
- 何らかの理由で Windows エクスプローラーからディレクトリ構造を参照する場合は、ディレクトリ内のエントリ (ファイルとサブディレクトリ) を 10,000 未満に抑えてください。
- CLI ユーティリティまたはコードからのみ操作する場合は、10K の制限の方がはるかに柔軟です。
- あまり多くのサブディレクトリを作成しないでください。作成する各ディレクトリは、コピー時にコピーが実行する必要がある別の個別の操作です。
- 各ファイルがN個のディレクトリを作成する場合、ファイルシステムオブジェクトそのファイルによって作成されるコピー回数は 1+N となり、コピー回数は線形に増加します。
- 短い指数ツリー (つまり、3 層のディレクトリがあり、それぞれに 256 個のサブディレクトリがある) は、ディレクトリあたり 10K の制限に達する前に、驚くほど拡張できます。
- コードでアクセスする場合は、開く前にディレクトリ リストを解析するのではなく、直接開くようにしてください。多くの場合、失敗した fopen() の後にディレクトリ スキャンを実行する方が、ディレクトリ スキャンの後に確実に fopen() を実行するよりも高速です。
注意:
- ファイル数は不変ですが、ディレクトリ数は任意です。これら 2 つの数の合計が、コピー操作にかかる速度に影響します。
- 可能であれば、必要な場合を除いて Windows エクスプローラーで参照しないようにしてください。Windows エクスプローラーは大きなディレクトリをうまく処理できず、これについてできることはあまりありません。
答え2
私の回答には数学に関する有益な情報が沢山ありますディレクトリの複雑さは i-node にどのような影響を与えますか?
そうは言っても、さまざまなファイルシステムが、ディレクトリ内の多数のファイルをさまざまな方法で処理します。10,000 エントリでも問題ないファイルシステムもあれば、問題になるファイルシステムもあります。すぐに思いついた経験則として、設計を制御できる場合は、1,000 が適切な上限値です。ディレクトリ内のエントリは通常、何らかのリストとして保存され、その順序を並べ替えるのは読み取りアプリケーションの役割です。たとえば、lsUnix の世界では、ディレクトリの順序でメモリに読み込まれ、アルファベット順に出力されます。
他の質問の計算を見てみましょう。また、sysadmin1338 が Explorer の動作が異なると言っていることも考慮してください。Explorer は、画像として認識したもののサムネイルを作成し、そのサムネイルを読み取って表示します。ファイルがぎっしり詰まったディレクトリを調べるには、大量のディスク IO が必要です。
答え3
このようなシステムを開発するリソースがあるかどうかにもよりますが、これはSQL Serverデータベースを使用するのに適した候補のようです。ファイルストリームファイルのストレージ。この方法では、ディレクトリの編成は SQL Server に任せ、データ自体の管理方法だけを気にすればよいことになります。データベース サイズの計算では FILESTREAM データは考慮されないため、SQL Express を使用できる可能性があります。