これは実際、Web アプリケーションでは非常に一般的です。作業する詳細があまりないので、考えるべきことと一般的な提案をします。
「自分で作成する」場合、アップロードしたバイトをデータベースに保存することは望ましくありません。それは可能ですが、特に人々が任意のサイズのファイルをアップロードする可能性がある場合、それをうまく行うのは非常に困難です。以前にこのナットをクラックしたことがありますが、私は最高の抽象化から始めると言います。ユーザーはファイルをアップロードでき、ファイルの場所を含む URL が返されます。したがって、ユーザーがファイルを POST すると、通常は新しいファイルの URL を含む 201/204 の応答が返されます。ソケットを使用している場合でも、同じサービスを複数の種類のクライアントとプラットフォームに展開できるように、HTTP ベースのアプローチを検討します。ただし、ソケットで非常に効率的な実装を作成できる可能性があります。
ソケットまたは HTTP リクエストのいずれを使用しても、以下はサーバー側で同じになります。サーバー側には、ファイル ID とユーザーを受け取る FileLocator などのインターフェースがあります。FileSystemFileLocator は FileLocator を実装し、ファイルシステム上のファイルを見つけます。注意が必要なのは、1 つのディレクトリに約 1,000 を超えるディレクトリまたはオブジェクトを置かないことです。一般的な手法 (各ファイルに一意の番号を割り当てる場合) は、ゼロを埋めて番号を逆にすることで、12 個の番号を作成します。3 桁の各ブロックがディレクトリ名になり、最後の 3 桁がファイル名になります: /123/400/000/000.pdf。きれいなファイル名を取り戻すには、データベース内の場所、元のファイル名、およびいくつかのメタデータを追跡します。
次に、S3 を使用してファイルを保存する S3FileLocator を実装できます。MongoFileLocator を使用してデータを mongo などに保存します。課題は、データベース内のメタデータ (非常に迅速にアクセスできる) が、ファイルシステムまたは S3 上の現実と同期されていることを確認する方法を理解することです。 .
ファイルを読み取るときは、ファイルの小さなチャンク (16k など) のみを読み取り、完了するまでそれらをループでユーザーに返します。ファイルを一度に読み込むと、メモリの使用効率が非常に悪くなります。たとえば、あるプロジェクトでは、SQL Server テーブルからメモリにファイルを読み取り、メモリ内でオブジェクトをコピーしてクライアントに書き戻すことで、これを実装しました。データベースには 50 メガバイトのパワーポイント プレゼンテーションが含まれていました。