質問: ユーザーがアップロードしたファイルをWebサーバーに保存する 私はユーザーがファイル(写真など)をアップロードできるWebサイトで作業しています。私はこの分野でこれまでの経験は全く持っておらず、これらのファイルを保存し索引を付けるための正しい方法で何らかのインプットを得ることを望んでいました。 大量のデータにうまく適応できるアーキテクチャを作りたいと思っていますが、現在は非常に高い(facebook-、google-scale)のボリュームは心配していません。 私は、ファイルシステムにファイルを格納することを考えていました。 ``` /files/{username}/ ``` そして、各ユーザが自分がアップロードした各ファイルのファイル名(とURL)を持つ自分のテーブルを持っているデータベース(と私が保存したいかもしれないその他の追加情報)を`アップロード`すること。 このデータベースの終わり(各ユーザに独自のテーブルを与える)は非常に非効率的ですが、1つのテーブル内のすべてのファイルの記録を維持することは正しいとは思わないだけでなく、1つのファイルが存在するたびにテーブル全体を検索する必要がありますアクセスされました。 各ユーザーに独自のテーブルを提供することを検討している私の考えは、テーブルをまたがってデータを断片化し、ユーザーに与えられたファイルを探すときの検索時間を短縮するきわめて明確な方法です。
回答: どの Matt H が提案したのは、あなたはユーザーレベルの画像アクセスを達成しようとしています。しかし、あなたのデータベース格納スペースが限られていることを認め、バイナリデータにイメージを保存することは、あなたが述べたように非効率的です。 ユーザーあたりの表を使用するとデザインが悪いです。ファイルをアップロードしたユーザーは、すべてのファイルアップロードを格納するテーブル内のフィールド/列である必要があります。一意であることが保証されているファイル名のGUIDを生成することをお勧めします。ユーザーが単純にすべての画像にアクセスできないようにしようとしている場合、簡単に推測できる自動インクリメントフィールドよりも優れています。 あなたはパフォーマンスを懸念していますが、何百万ものレコードを処理するまでは、画像を選択するためのクエリはユーザーに属し、特定の時間枠内にアップロードされます(タイムスタンプなどを保存しています)。スピードが問題になる場合は、ユーザ名にBツリーインデックスを追加すると、ユーザ固有の画像クエリを大幅に高速化できます。 セキュリティ、アクセス、および組織のトピックに戻ります。ユーザーごとにフォルダに画像を保存します(ただし、ユーザー数にもよりますが、フォルダの数が管理不能なレベルに増加する可能性があります)。イメージを公開したくない場合は、Web以外のフォルダに保存し、アプリケーションでデータを読み込んでストリームして、そのイメージをユーザーに表示させます。より複雑ですが、実際のファイルをインターネットから隠すことができます。また、認証されたユーザーがイメージのすべての要求を検証できるようになります。