多数の画像を保存するためのSQL Serverテーブル構造

Question

SQL Server 2008に大量の画像データを保存するためのベストプラクティスは何ですか？約5ギガのストレージスペースを使用して、約50,000枚の画像を保存する予定です。現在、列を持つ単一のテーブルを使用してこれを行っています：

ID: int/PK/identity
Picture: Image
Thumbnail: Image
UploadDate: DateTime

心配しているのは、予想される合計容量の約10％で、挿入に時間がかかっているように見えるためです。典型的な画像は約20k〜30kです。このデータを保存するためのより良い論理構造はありますか？または、データの負荷に対応するためにクラスタリングまたは他のITソリューションを検討する必要がありますか？

Answer 1

Image は、SQL Server 2008で非推奨のデータ型です。SQLServer 2005以降、 VARBINARY（MAX）に置き換えられています。画像を保存する場合DBの場合は、 VARBINARY（MAX）フィールドを使用し、 FILESTREAM オプションの追加を検討する必要があります。

画像のようなストリーミングデータの場合、 FILESTREAM は、このホワイトペーパー：

_{（ソース： microsoft.com ）}

このストリーミングパフォーマンスを実現するには、設計で適切なAPIを使用し、 BLOBのWin32ハンドル。 FILESTREAM 列への更新（ INSERTS を含む）は、 VARBINARY（MAX）よりも遅いことに注意してください。

Answer 2

DBへ、またはDBへではない、それが問題です。

ここでDBの画像を使用して宗教戦争を開始しています。

SQL 2000については意見が分かれますが、2005年以降はBLOBを保存するかなりまともな仕事をします。MSSQL Serverをストレージとして使用するSharePointインストールの数を見てください。私はこのルートをマイナーな画像保存のためだけに行きます。

それらをDBに置くことになった場合、クエリを簡単にし、開発者が SELECT * （はい、そうです）。

SQL 2008でFILESTREAMをチェックしてください-これはこのようなものを対象としています。

ここでは、DBとファイルシステムに関する他のポイントを検討します。

• DBストレージ、バックアップ、復元、メンテナンスライセンスは高価です
• DBのストレージはディスクよりも取得が困難です
• ディスクを高速化できます
• DBで画像を取得/設定するためのコードを記述する必要があります-ディスクには不要です

Answer 3

SQL Server 2008の新しい Filestream 機能をご覧ください。基本的に、データベースにblob（読み取り：イメージ）データを格納できます。読み取りおよび書き込みのたびにデータをsqlバッファーに読み込むオーバーヘッドは発生しません。 sqlページではなく、filesystemをシームレスに使用して大きなファイルを保存します。これにより、大きなファイルの読み取りおよび書き込み時間が大幅に短縮されます。何よりも、これらはすべて内部で発生するため、既存のストアドプロシージャを変更してファイルストリーム列を処理する必要はありません。コードサンプルとパフォーマンスプロファイリングについては、こちらをご覧ください。