php - データベースの設計と画像ファイル システムの管理?

Question

ユーザーがアップロードした画像を受け入れ、名前を変更してファイル システムに保存するためのバックエンドを構築しようとしています (いいえ、Instagram ではありません)。

単純に画像の名前を変更してユーザー フォルダーに保存することを考えていました。

images/{userid}/{userid}_{md5(タイムスタンプ)}.jpg

関連付けもデータベースに含まれます。

それは良い/十分なモデルですか？

Answer 1

基本的にあなたの方法は問題ありませんが、ここに私の提案があります：

• ファイル名にタイムスタンプを使用しないでください。すでにファイル名をDBに保存しているため、タイムスタンプ<->ファイル関係用に追加の列を作成するだけです。このようにして、元の作成、最終変更日、さらには有効期限などを簡単に管理できます。
• 保存するファイル名の列が一意であることを確認してください。誤って重複したファイル名を保存したくない
• ファイルの受け入れについてクロスチェックを行います。ファイルがサーバーに正常に保存されてもクエリが失敗する場合は、失敗したときにファイルを削除してください。または、操作の順序が逆で、ファイルをサーバーに保存できない場合は、DB のエントリを削除します。
• 画像へのアクセスが許可されていない場合は、画像の表示を通常どおりに拒否し、代わりにファイル名を GET 変数として使用してリンク (PHP ファイル) にユーザーを誘導できます。次に、SESSIONS および/または COOKIES をチェックして、表示する権限があるかどうかを判断できます。そうである場合、出力のヘッダーを jpeg または表示しているファイルの種類に設定できます。

Answer 2

データベースの一意の ID を使用しないのはなぜですか。これにより、ファイルの検索がはるかに簡単になります。

また、ファイルの構造を制限しません。おそらく、常にユーザー名で保存する必要はありません。各ファイルにデータベースに関連付けられた ID がある場合、これははるかに簡単になる可能性があります。

user/{database_id}.jpg

Answer 3

ちょっと依存します：

• ユーザーあたりの画像数は?
• 画像あたりのおおよそのサイズ範囲?
• ユーザー数は？
• どのような種類の同時実行を期待していますか?

上記の数値のほとんどが小さい場合、あなたの方法はおそらく十分に長い道のりを歩むのに十分であり、少なくとも始めることができます.

MySQL ブロブ ストレージを使用すると評判が悪いことは承知していますが、それも簡単に開始できる方法であり、巧妙なコーディングを行うことなく、データベースを分割してスケールアウトすることができます。

それは言った...

システムで、ユーザーが非常に多数のファイルをアップロードすることが予想される場合、ファイルシステムの制限またはパフォーマンスの問題が発生する可能性があります。

Windows でホストしている場合は、ファイル名が 8.3 よりも確実に長くなるため、8.3 のファイル名の問題(ディレクトリが大きくなると非常に遅くなる) に注意してください :)

多くの人が同時にアップロード/ダウンロードする場合 (使用のピーク時など)、I/O の競合に注意する必要があります。RAID 10 ボリュームを使用している場合は、SSD を使用するとさらに効果的です (ただし、ストレージ容量の問題が発生する可能性があります)。

提案された方法は、同じ画像が別の人によってアップロードされる可能性がある場合 (多くのフォルダー間で重複)、最もスペース効率が良くありません。その場合、データの関数 (例: md5sum) を作成し、コピーを 1 つだけ保存します (はい、削除には管理上の問題があります)。

多くの人から大量の大きな画像が予想される場合は、最終的には基盤となるストレージのスケーリングについて考える必要があります。{userid} の何らかの機能によってデータを分割し、異なるボリュームまたはマシンに分割することができます。これにより、同時スループットも向上します。

もう 1 つの質問: 常に元の画像のみを提供するのですか?それとも、サイズを変更したコピーを時々送り返すのですか? おそらく、一度スケーリングして、常にスケーリング前のバージョンを返したいと思うでしょう。その場合、それらのスケーリングされたコピーのストレージも考慮する必要があります。