ファイルシステムに画像を保存してURLを返すか、仮想的にサイズを変更してバイト配列を返しますか？
REST Webサービスを作成して、ユーザーが送信した画像を管理し、それらをすべてWebサイトに表示する必要があります。このサービスを使用して画像を管理および表示するWebサイトは複数あります。要件は次のとおりです。 5つの事前定義された画像サイズを利用できるようにします。
私が見る2つのオプションは次のとおりです。
Webサービスは5つの画像を作成し、それらをファイルシステムに保存し、ユーザーが画像を送信したときにURLをデータベースに保存します。画像がリクエストされると、WebサービスはURLの配列を返します。
このオプションはハードドライブ上で少し難しいと思います。推定では、サイトあたり10,000ユーザー、たとえば100サイトです。ユーザーが画像を送信し、各画像がファイルシステムからプルされるときに、重い処理が実行されます。
Webサービスは、ユーザーが送信した画像のみをファイルシステムに保存し、そのURLをデータベースに保存します。ユーザーが画像をリクエストすると、WebサービスはDBから情報を取得し、メモリに画像を読み込み、その5つのインスタンスを作成し、5つの画像配列を持つオブジェクトを返します（おそらく配列をキャッシュします）。
このオプションは、プロセッサとメモリでは困難です。重い処理は、画像が要求されたときに行われます。
オプション2のプラス点は、イメージのURLを書き換えて、すべてのWebサイトのイメージリポジトリよりもサイトに依存する（きれい）ようにするオプションがあることです。しかし、これは大したことではありません。
これらのオプションについてどう思いますか？他に何か提案はありますか？
それが古典的なCDNでも、曇ったものでも、独自のロールでも、ファイルストアを確実に使用してください。また、5つの画像サイズすべてをわざわざ保存することもしません。最初のアクセスで、オンザフライで拡大縮小された画像を作成します（つまり、特定の画像とサイズのDBクエリがURLに対してNULLを返した場合、より大きい画像を縮小して、新しく作成されたURLを返し、それを保存します。将来の参考のために）。
ハードドライブについてはあまり気にしないでください。関連するすべてのOSにはすでに非常に効果的なファイルキャッシュがあり、それを打ち負かすことは難しいでしょう。さらに、100万人のユーザーにサービスを提供することを計画しています。ユーザーあたり1ドルで妥当なストレージを見積もることができ、十分にお金を使うことができます。
URLの美しさについて心配する必要はありません。私たちのファイルストアはdownload.<OurCompanyName>.comとして知られていますが、有名なCDN会社によって実際にホストされています。
私はむしろそれらをイメージサーバーでホストし、データベースからそれらにリンクしたいと思います。データベースは巨大なblobの処理があまり得意ではありません。
たとえば、AWSスイートを使用している場合、DynamoDBにデータ（最大64kb）を保持し、実際のイメージをS3に配置します。 （地理的な分布/膨大な可用性が必要な場合は、CDNを使用できます）。データベースによっては、そのような解決策が1つ見つかります。
そして、はい-FSがS3と同じくらい利用可能であり、これらの長期的な永続性/バックアップについても検討したことを確認してください。データベースがバックアップ/復元されると、FSは同じポイントに復元する必要があります。そうしないと、非常に奇妙なバグが発生します。このストアを自分で構築する場合、実際には実装がはるかに困難です。