1つのディレクトリにたくさんの画像を保存すると、画像検索が遅くなりますか？

Question

私は、ユーザーが好きなだけ多くの画像をアップロードできるサイト（photobucketのようなものだと思います）を持っている場合、ファイルの保存場所を設定する最良の方法は何ですか（また、すべてのアップロードに一意のランダムタイムスタンプが付いています）。

site root 
--username 
----image1.jpg 
----image2.jpg 
----image3.jpg 
--anotheruser 
----image1.jpg 
----image2.jpg 
----image3.jpg 
... 

または

siteroot 
--uploads 
----image1.jpg 
----image2.jpg 
----image3.jpg 
----image4.jpg 
----image6.jpg 
... 
----image50000.jpg 

私は最初の方法は、より組織的だと思います。しかし、私は2番目の方法は、（同じディレクトリにすべてのアップロードを維持）標準だと思うが、同じディレクトリに何千もの画像がある場合、画像を取得するときは遅くなるのだろうか？

---編集 - -

これまでの素晴らしい答えに感謝します。 また、サムネイルを作成するので、そのディレクトリをどこかに挿入する必要があります... または、thumb_whatever.jpgなどの命名規則を作成してください。

これを行うにはさまざまな方法があります。 はいのディスク容量が問題になります。しかし今のところ私は検索時間に関係しています。ブラウザにイメージを出力する必要があるとき、そのイメージが10,000のイメージを持つディレクトリにある場合、それはどのくらい遅くなるか心配です。

Answer 1

ディレクトリ内のファイルの数は、ファイルのデータを読み取るために必要な時間には何も影響しませんが、ファイルの読み取りを開始するまでに時間がかかります。

重要な問題が起きる正確なブレークポイントは、ファイルシステムのタイプによって異なりますが、一般に、数百のファイルについて話す場合は、それほど心配する必要はありません。もしあなたが数千語話しているのであれば、あなたのファイルシステムとハードウェアがそれをどのように処理するかを見るために、ちょっとしたベンチマークを考えて、おそらく価値があります。何万ものファイルについて話しているのであれば、本当に分裂を開始する必要があります。 （以前は、Linux/e2fsプリントサーバーを使用していましたが、CUPSは印刷後にジョブ制御ファイルを削除せず、1つのディレクトリに約10万件のファイルが保存されていました。任意のファイル名を表示することができます）。

ユーザー名で区切ることは最適ではない可能性があります。多くのユーザーが非常に少ない画像をアップロードする可能性があります。おそらく数百または数千の画像をアップロードするカップルそれらのユーザーのストレージディレクトリにアクセス時間の問題が発生します。そのシナリオでのより大きな問題は、ユーザーが数千人から数万人に及ぶ可能性が高く（サイトが成功したと仮定して）、サブディレクトリの数が多いことは、多数のファイルほどアクセスが遅いデータ。

あなたはタイムスタンプを持っているので、私はおそらくに基づいてサブディレクトリに入れます。タイムスタンプの3桁です。これにより、1000個のサブディレクトリに比較的均等にファイルが配布され、各ディレクトリ内のファイル数は適度に少なくなります。 （最初の3桁を使用すると、1つのディレクトリがいっぱいになってから、次のディレクトリに移動する前に、それらのディレクトリを均等に分散する必要はありません）。各サブディレクトリにまだファイルが多すぎる場合はアップロードされた画像数が100万件の場合）、前の3桁の2番目のレベルを追加することができますので、upload-1234567890.jpgは/567/890/upload-1234567890.jpgになります。 #IDはOFCである アップロード/（＃IDは％1000）/img_#id.jpg

：

Answer 2

私は、uploadsディレクトリの下のサブディレクトリが最適だと思います。

site root 
--uploads 
----username 
------image1.jpg 
------image2.jpg 
------image3.jpg 
----anotheruser 
------image1.jpg 
------image2.jpg 
------image3.jpg 
... 

ホストOSによっては、1つのディレクトリにファイルが多すぎると頭痛や互換性の問題が発生する可能性があります。また、イメージリストの取得方法によっては、パフォーマンスの問題が発生する可能性があります。

さらに、オプション2は混乱します。 :)

Answer 3

その答えは "多分"です。ファイルの取得は可能かもしれませんが、フォルダのメンテナンスが必要な場合は、プロセスがディレクトリリストを列挙しようとすると大きな頭痛になります。

状況は（あなたが保存を見ているどのように多くの画像によって、あるいは二つのレベル）の画像フォルダの下にサブディレクトリの数だろう改善するだろう何

ので、あなたはこのような階層構造を持っている：

siteroot 
-- uploads 
---- a 
---- b 
---- c 
    : 
---- z 

...最初の文字に基づいてファイルを保存します（ 'a'から始まる名前を持つすべての画像は 'a'フォルダに移動します）。これを2文字または3文字のサフィックス（aa、ab、ac、ad ...、ba、bb、bc ...、zx、zy、zz）にすることもできます。名前の最初の4文字に依存するいくつかのフォルダにわたるファイル。

ファイルにランダムな英数字の名前が割り当てられている場合、ファイルがすべてのフォルダに均等に分散されます（サンプルサイズが十分にある場合）。

上記のように、オプション（1）と階層の上に画像を分割することが考えられます。そうすれば、1人のユーザーがたくさんのファイルをアップロードしても、それは確実にカバーされます。同様に、多くのユーザーディレクトリを見ている場合、同じ原則が適用され、単一の親の下に1,000,000のユーザーディレクトリが存在しないようにします。

Answer 4

試してみてくださいmongodb ...これはバイナリデータを格納することを可能にするkeyvalue dbです。非常に高速で効率的で、シャーディング（複数のマシンにデータを置く）をサポートします。

あなたは本当にファイルとフォルダをいっぱいにしたくありません。これらのフォルダを管理することは永遠に必要であり、後で命名/分割スキームを変更することは悪夢です。さらに、diskspaceを使い果たした場合、問題が発生します。また、ロードバランシングの場合、1つのハードディスクにファイルがいっぱいであると効率的ではありません。

Answer 5

ファイルシステムによって異なります。たとえば、ディレクトリに512を超えるファイルがあると、FAT16はかなり遅くなる傾向があります。 FAT32とNTFSには同じ制限がありませんが、非常に大量のファイルがある場合はさらに遅く実行されます。より堅牢なLinuxファイルシステムを実行している場合でも、ディレクトリが小さければより迅速に解析することができます。

私は間違いなく＃2に行くでしょう - 画像をユーザごとにディレクトリに分割します。

Answer 6

私はしばしばこのようにスキーマを使用しています。データベースに格納されている写真のID番号（整数）。これは、写真のIDだけに基づいて簡単なスキーマを提供します。