it-swarm-ja.com

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

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

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

他の誰かが数百万の画像の課題に対処していますか、どのように対処しましたか?

12
Webjedi

数百万のイメージはありませんが、数十万のイメージがあり、メタデータには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

6
mooreds

データベースに画像/バイナリデータを保存しないでください」と言う人は無視してください。 VarBinaryタイプの列にデータを保存する)。 SQL Serverを使用して画像を保存するパフォーマンスの問題は、SQL Server 2008で FILESTREAM データ型を使用することで軽減できるようになりました。本質的に、FILESTREAMデータ型を使用すると、 NTFSファイルストアからファイルを提供することで得られるパフォーマンスを備えたデータベース。

SQL Mag を引用するには:

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

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

3
Dan Diplo

それらをファイルシステムに保存することにした場合は、このServerFaultの質問でいくつかのことを行ってください: ファイルシステムに100万個の画像を保存する

3
Mark Henderson

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

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

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

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

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

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

1
Gary