多くの画像（> 100,000）をWebサーバーに保存する予定です。
ファイル名は例になります。
324-2012-07-25-143544.jpg
ファイル名は次のように作成されます。
userid-year-month-day-HHMMSS.jpg
このファイル名はmysqldatabaseに保存され、読み取られ、ファイル名からファイルパスがわかります->
images / userid / year / month / day / userid-year-month-day-HHMMSS.jpg
したがって、この例では次のようになります
images / 324/2012/07/25 / 324-2012-07-25-143544.jpg
すべてがベースフォルダ/画像に保存されるときに発生する可能性のあるパフォーマンスの問題はありますか？
ありがとう！
あなたが行っているように、ファイルをシャーディングすることは、1 つのディレクトリに多くのファイルがある場合のパフォーマンスの問題を回避するための優れた方法です。この方法では、特定のディレクトリにいくつかのエントリ (ディレクトリまたはファイル) のみが存在するようにします。必要に応じて、複数のボリュームに分割することも簡単です。高レベルのディレクトリのいくつかを別の場所にマウントするだけです。
ただし、いくつかのことを考慮する必要があります。
これらの画像を基本的に永続的に保存する場合は、ID に基づいて分割することをお勧めします。これは、DB 側から処理する方が少し簡単です (DB 設計で任意の主キーを使用するのと同じ理由で)。
@Veger が示唆するように: imageid123456は になり/12/1234/123456.jpgます。
ただし、日付、ユーザー ID、または自動インクリメント番号を使用すると、比較的推測しやすく、誰かがすべての画像を簡単に取得できるという点で、セキュリティ リスクが生じる可能性があります。
さらに、ユーザーがアップロード日を知る理由がない場合、URL に日付が含まれていると、情報が漏洩する可能性があります。
非常に推測しにくいキーを使用している場合は、ハーベスティングと情報漏えいの両方に対してある程度のセキュリティが提供されます。たとえば、GUID を使用できます。イメージ ID6f33395e-eda8-4486-8b8e-51ea0f91751bは として保存され/6/6f33/6f33395e/6f33395e-eda8-4486-8b8e-51ea0f91751b.jpgます。
非常に多くの GUID (128 ビット) があるため、誰かがすべてを収集するには数百万年かかる可能性があります (1 時間あたりの IP ごとの接続を制限するなどの追加の手順を実行しなくても)。
イメージが揮発性である場合 (つまり、一定の時間が経過すると有効期限が切れる場合) は、実際には日付構造に基づいて分割するのが最善かもしれません。たとえば/2012/12/14/2012-12-14-hhmmss-userid.jpg、これを GUID と組み合わせて/2012/12/14/6f/6f33395e-eda8-4486-8b8e-51ea0f91751b.jpg.
2011 年のファイルをすべて削除する場合は、rm -rf 2011. これを使用する良い例は、ログ ファイルです。
データベースでクエリを実行して日付に基づいて古い画像を検索し、それらを 1 つずつ削除することができるため、これは非常に多数の画像に対してのみ意味があることを覚えておく必要があります。
最終的に保存する予定のイメージを増やすには、より高い粒度のシャードを使用してください。
目標は、ディレクトリごとのエントリ数をファイルシステムが処理できる数に保つことです。経験則としては、最大で約 10,000 のようです。サイトが今後しばらく獲得するトラフィックを予測する必要があります。ただし、ある時点で 1 日に何百万ものユーザーがいるかもしれないと考えて、夢中にならないでください。再シャードすることは不可能ではありませんが、それは苦痛です。今後数年間の成長を予測し、それに対処してください。より速く成長し、結果として再シャードする必要がある場合は、解決するのが良い問題です. ディレクトリ エントリがイメージよりも多くのスペースを占めているためにディスク容量が不足している場合、それは対処するのがばかげた問題です。
私はこのようにします：
たとえば、画像番号1はとして保存され/0/1.jpg、画像番号1234567はとして保存され/123/1234567.jpgます（10000個のファイルをディレクトリに保存できると仮定します）。
最も簡単で、ノイズの量を最小限に抑え、ディレクトリ内のファイル数を最適化します（半分いっぱいのディレクトリを大量に浪費する代わりに）。
本当にたくさんの画像を保存する場合は、2つのサブディレクトリを使用してください。のように、/0/0/1.jpgそして/1/12345/123456789.jpg