SQLサーバーとファイルシステムとS3などからのイメージの提供

私のアプリケーション（クラシックasp yay！）には25 GBで約210万の画像があり、これは90日間のデータを表しているだけなので、少なくとも365にしたいと思います。これらを制御する必要があり、すべてのオプションを検討しています。次のプラクティスの長所と短所についてはどう思いますか？

• SQL Serverの長所：バックアップが簡単短所：パフォーマンス？
• ファイルシステムの長所：速度の短所：冗長性、バックアップが遅い（代わりに、合成フルバックアップを実行することを研究しているので、より良い可能性があります）
• S3などの長所：帯域幅は私のデータセンターからAmazonにシフトされ、実質的に無制限のストレージです。短所：コスト、コスト分析は難しい（帯域幅の80％がROI目的の画像であると推定される）、それが必要になった場合、サービスプロバイダーにとって難しい/コストがかかる

他の誰かが数百万のイメージの課題に対処し、どのように対処しましたか？

数百万のイメージはありませんが、数十万のイメージがあり、メタデータにはmysql、バックアップ用にローカルディスクに保存されたイメージ、ユーザーに提供されるAmazon s3にプッシュされるハイブリッドアプローチを使用します。Amazonと可用性に問題はありませんでした。クラウドフロントへの移行は私たちの計画の中にあり、時間を見つける必要があります。

この議論はあなたの決定に役立つかもしれません：http :
//ask.metafilter.com/59635/Millions-of-images

SQLサーバーのメタデータとファイルシステム（またはs3またはcloudfront）のファイルを使用します。しかし、最良の答えは他のいくつかの使用パターンに依存します。

• 画像は頻繁に変化しますか
• ファイルシステムから直接画像を提供できますか（つまり、img src="..."）、アクセス制御する必要がありますか。後者の場合、データベースソリューションが最適です
• ほとんどの場合（最新の10％）、少数の画像を提供していますか、それとも比較的広範囲に分布しています。

何百万もの画像のバックアップは、どのように配置しても複雑になります-それはただの大量のデータです。このソリューションに取り組む前に、SQLサーバーのBLOBのバックアップに関する優れたケーススタディを見つけたいと思います。（役に立つ記事があります：http : //www.databasejournal.com/features/mssql/article.php/3738276/Storing-Images-and-BLOB-files-in-SQL-Server-Part-4.htm）

それらをファイルシステムに保存することに決めた場合は、このServerFaultの質問を読んで、するべきこととしないことを確認することができます。

古い情報に基づいて回答を行っているため、「データベースに画像/バイナリデータを保存しないでください」と言う人を無視します（VarBinaryタイプの列にデータを保存すると仮定します）。SQL Serverを使用して画像を保存するパフォーマンスの問題は、SQL Server 2008のFILESTREAMデータ型を使用することで軽減できるようになりました。 NTFSファイルストアからのファイル。

SQL Magを引用するには：

「SQL Server 2008の新しいFILESTREAMサポートは、NTFSファイルシステムからLOBに直接アクセスする利点と、SQL Serverリレーショナルデータベースエンジンによって提供される参照整合性とアクセスの容易さを兼ね備えています。」

詳細については、MSDNのRavi S.Maniamによるこのブログを参照してください。

私は数百万の画像チャレンジに対処していませんが、Amazon CloudFrontを使用します。すべてのファイルはS3バケットに格納されますが、Amazonのコンテンツ配信システムを介したサーバーです。S3を単独で使用することはありません。

2番目の選択肢はファイルシステムです。シンプルで簡単なのは、これらのファイルがすべて1つのディレクトリに配置された場合、すべてが激しくクラッシュするという唯一の問題です。

私にとってSQLは、このようなシステムのオプションではありません。帯域幅の転送に対して課金されるだけでなく、クエリの処理に対しても課金されます-これはホスティングに大きく依存しますが、専用のサーバーまたは少なくとも課金されるvpsを使用していると仮定しますサイクル用。その後、イメージサーバーと同じデータベースを使用すると、サイト全体が遅くなります。そうでない場合は、2つのデータベース接続を管理する必要があるというこの複雑さをすべて追加します。

データベースは、トランザクションデータ/一貫性とセキュリティのために設計されています。

メディアファイル（画像、音声、ビデオ）は作成されたり削除されたりする傾向がありますが、更新されることはほとんどありません。そのため、一般的に、他のデータとトランザクションの一貫性を保つ必要はなく、データベースはそこに実際の利益を与えません。テキストコンテンツは別の問題かもしれません。

ファイルのURLを知っている人がファイルを直接プルするという概念に問題がない限り、ファイルシステムは問題ありません。人々がファイルをダウンロードする前に充電すると予想される写真ライブラリのようなものを実行している場合、それはおそらく異なる問題です。つまり、ユーザーが支払いを済ませると、そのユーザー固有のURLまたは短時間だけ有効なURLを取得でき、アプリケーションは同じ画像を指す複数のURLまたは一時的なURLを処理します。それでもアプリとファイルシステムで処理できますが、最終的にはファイルを直接ダウンロードするのではなく、アプリケーションを介してメディアを提供することになり（S3のメリットはほとんどありません）、DBとファイルシステムの違いはほとんどありません。 。