ファイル（BLOB）が多すぎるSQL Server DBを処理する方法は？

シナリオ：
ASP.NETアプリケーションにサービスを提供するSQL Server 2005データベース（別のWebサーバー上）。

データベース：
DBには、約5GBの「通常の」データと約15GBの「ファイル」があります（例：画像（BLOB）として保存された200k PDFなど）。より多くのファイルがユーザーによってアップロードされており、急速に多くのディスク領域を消費しています（DBは、今後数か月で50GBに増加する可能性があり、ほとんどがファイルです）。

懸念事項：
DBに非常に多くのファイルを保存すると、既に問題が発生しています（例：データベースの合計サイズが大きいと、DB全体のバックアップと展開が時々難しくなります。）。

そして、さらに問題が発生するのではないかと心配しています。（例：パフォーマンスの問題-おそらく、DB全体をRAMに保持できないことが原因でしょうか？）

質問：
この問題に対してどのような技術的解決策を提案しますか？ファイルをファイルシステムに保存しますか？データベースを2つに分割し、ファイル用に大きくて遅いファイルを持っていますか？

必要に応じてさらに詳細：
これらのファイルはそれほど重要ではなく、非常に高速なアクセス時間を必要としません。現在、数秒で十分ですが、現在1時間あたり数十の選択があります。DBの他の「通常の」データには、毎秒何回も必要な情報が含まれています。

私は非常によく似たデータベースを管理しています。現在3TBで、1日あたり5GB増加しています。

• Filestream（2008以降）は、バックアップ/復元の問題を解決しません。
• ファイル> 1メガバイトのためのより良いLOB記憶域よりのFileStreamを行い、そのポールランダルのテストは述べています。256KB-1MBでワークロードに依存し、一般的に256KB未満で悪化します。
• 一部の環境でのFilestreamの大きなプラスは、バッファープールをバイパスし、代わりにWindowsシステムキャッシュを使用することです。
• ファイルをファイルシステムに置くと、データベースレコードとのトランザクションの整合性が失われます。また、数百万の個々のファイルをバックアップするオーバーヘッドも追加されており、面倒な場合があります。

Filestreamの賛否両論を比較検討し、それがあなたのケースに適合するかどうかを確認します。私たちのケースでは、我々は別のルートを取ったし、我々が利用することができるように、データベースを分割を選択しました断片的な復元/一部使用可能。

私たちが利用できなかった1つのオプションは、古い/アーカイブファイルグループを読み取り専用としてマークすることです。その後、読み取り専用ファイルグループをまれにバックアップできます。

2005 Standard（パーティショニングはEnterpriseエディションの機能）で立ち往生していて、履歴を読み取り専用にするオプションがある場合、これを昔ながらの方法で取り組むことができます。

• テーブルを分割します。たとえば、月ごとのテーブルに基づいて、アクティブ/履歴ルートまたは日付を考慮することができます。
• 履歴データを読み取り専用のファイルグループに配置し、さらにデータをアーカイブするときにのみバックアップします。これにより、バックアップ時間が短縮されることをユーザーに理解してもらいます。部分可用性機能がない場合、復元にはしばらく時間がかかる場合があります。
• テーブルのパーティション分割ビューを作成します。

最後のオプションの1つ（3 TBブロバーについて検討中）は、ファイルデータをドキュメントデータベースまたはクラウドストレージ（AmazonS3、Azure BLOBストレージなど）に移動することです。これにより、前述のトランザクションの整合性の問題が発生しますが、非常に高価なSQLサーバーから負荷が取り除かれます。

SQLサーバーのFILESTREAM機能を試してください。

FILESTREAMは、ファイルシステム上のファイルとしてvarbinary（max）バイナリラージオブジェクト（BLOB）データを格納することにより、SQL ServerデータベースエンジンをNTFSファイルシステムと統合します。

それについての素敵な記事

1. SQL Server FileStreamの概要
2. BLOBを使用するかしないか：データベースまたはファイルシステムのラージオブジェクトストレージ
3. SQL Server 2008のFILESTREAMストレージ