Programming with FileStreams in SQL Server 2008

[アーティクル]
06/11/2015

開発者によるデータベース構築

SQL Server 2008 で FILESTREAM を使用してプログラミングを行う

Bob Beauchemin

コードは MSDN コードギャラリーからダウンロードできます。
オンラインでのコードの参照

Transact SQL を使用して FILESTREAM のプログラミングを行う
ファイル入出力を使用して FILESTREAM のプログラミングを行う
SqlFileStream .NET データ型
FILESTREAM とトランザクション
FILESTREAM での機能の相乗効果

ドキュメントやマルチメディアアイテムなどの大きい BLOB (Binary Large Object) をデータベースとファイルシステムのどちらに格納すればよいかについては、常に活発な議論が行われています。データベースは、統合された組み込みのバックアップと復元、特定の時点への復旧、トランザクション、インデックス作成、その他さまざまな機能を提供する特化したデータリポジトリです。しかし一方で、大きいデータをデータベースに格納するとデータベースの断片化を引き起こします。また、大きいオブジェクトデータは優れた復旧機能によってデータベース自体とトランザクションログにそれぞれ 1 回ずつ、つまり常に 2 回書き込まれます。SQL で大きいデータを読み取る場合も、貴重なデータベースバッファを使用して、メモリ内にキャッシュされるはずのデータを副作用としてディスクにフラッシュすることになります。

この論争にはっきりと決着をつけるため、Microsoft Research はこの件について調査し、結論を「To BLOB or Not To BLOB: Large Object Storage in a Database or a Filesystem? (BLOB にするかしないか: 大きいオブジェクトはデータベースとファイルシステムのどちらに保存するか)」というホワイトペーパーで公表しました (research.microsoft.com/apps/pubs/default.aspx?id=64525 を参照)。結論は「何でもデータベースに保存しよう」という意見には否定的であり、SQL Server 2005 データベースと NTFS ファイルシステムをテストした結果、推奨として示されたのは、「256 KB 未満の BLOB は SQL Server で処理する方が効率がよく、1 MB より大きい BLOB では NTFS の方が効率がよい。両者が均衡する位置は、データベースシステム、ファイルシステム、およびワークロードによって異なる」というものでした。両者の長所を活かそうとして NTFS ファイルの場所をデータベース行に格納するプログラマもいます。しかし、そうするとトランザクションの一貫性や統合言語クエリなどのデータベース機能が犠牲になります。SQL Server 2008 ではどちらかを選択する必要はありません。FILESTREAM 記憶域属性という新しい機能を使用して、データが実際はファイルシステムに格納されているという指定を含む列を SQL Server テーブルに定義できます。データのクエリには C++ または .NET 互換の言語で Transact SQL またはストリーミング API を使用でき、その他すべてのデータベース管理機能を変わらずに使用できます。このコラムでは、両方の種類の API を使用してこのハイブリッド記憶域モデルのプログラムを作成する方法について説明します。

最初に確認ですが、先ほどこの機能を FILESTREAM 記憶域属性と紹介したことにお気付きでしょうか。FILESTREAM は新しいデータ型ではありません。これは新しい記憶域メカニズムです。FILESTREAM は、SQL Server 2005 で導入された varbinary(max) データ型でのみ使用できます。FILESTREAM 記憶域を使用するには、システム管理者が SQL Server 構成マネージャを使用してオペレーティングシステムレベルで FILESTREAM を有効にし、データベース管理者 (DBA) が sp_configure を使用して SQL Server インスタンスレベルで FILESTREAM を有効にする必要があります。FILESTREAM は、無効、ローカルアクセスで有効、またはローカルアクセスとリモートアクセスで有効、にすることができます。さらに、DBA は、NTFS ファイルシステムの場所を SQL Server データベースに結び付けるデータベースファイルグループを定義する必要があります。ファイルグループはローカルファイルシステムの場所を指し示す必要があることに注意してください。FILESTREAM は、リモートサーバー上に置くことはできません。また、ネットワークアドレス指定可能ストレージ (NAS) デバイスが iSCSI を介してローカル NFS として存在していない場合は、NAS 上に置くこともできません。FILESTREAM へのアクセスは SMB (サーバーメッセージブロック) プロトコルを使用するので、SQL Server がインストールされているマシンの外部からのファイル入出力スタイルのアクセスを許可する場合は、ファイアウォール経由での SMB ポート (通常はポート 445、フォールバックとしてポート 139) へのアクセスを許可する必要があります。管理面での前提条件が満たされたら、テーブル定義の一部として FILESTREAM プロパティを設定した varbinary(max) 列を定義するだけで、この列のデータは自動的にファイルに格納されます。さらに、FILESTREAM 列を使用する各テーブルには、UNIQUEIDENTIFIER データ型を使用して定義した、ROWGUIDCOL プロパティを設定した列が必要です。Northwind データベースの FILESTREAM を使用するバージョンの Employees テーブルは、図 1 のようになります。

図 1 FILESTREAM を使用する Employees テーブル

CREATE TABLE [dbo].[Employees2](
  [EmployeeID] [int] IDENTITY NOT NULL PRIMARY KEY,
  [LastName] [nvarchar](20) NOT NULL,
  [FirstName] [nvarchar](10) NOT NULL,
  [Title] [nvarchar](30) NULL,
  -- filestream storage for photo column
  [Photo] [varbinary](max) FILESTREAM NULL,
  [ReportsTo] [int] NULL,
  -- identifier column
  [RowGuid] [UNIQUEIDENTIFIER]  NOT NULL  
        ROWGUIDCOL UNIQUE DEFAULT NEWID()
);

FILESTREAM は、従来のデータベースログと、従来のトランザクションログの拡張としてファイルの変更を記録する固有のログメカニズムの両方を使用します。拡張機能は標準の SQL Server データベーストランザクションログとは別のものであり、バックアップおよび復元のユーティリティと統合されています。管理およびデータベース内部の観点からの FILESTREAM の詳細については、Paul Randal の優れたホワイトペーパー「Filestream Storage in SQL Server 2008 (SQL Server 2008 での FILESTREAM 記憶域)」(msdn.microsoft.com/library/cc949109) を参照してください。

SQL Server プログラマから見ると、FILESTREAM オブジェクトは varbinary(max) データ型とほぼ同様に動作しますが、いくつか注意点があります。アプリケーションプログラムをまったく変更することなく、Transact SQL を使用してデータを照会できます。この記事のコードに含まれる簡単な Windows フォームアプリケーションは、DataGrid コントロールで先に定義した Employees2 テーブルを表示するために、特に変更する必要はありません。ただし、パフォーマンスに関する利点は、FILESTREAM 固有の API 拡張機能を使用してストリームベースの API でデータを読み書きしたときに得られます。もう 1 つの利点として、FILESTREAM ベースの varbinary(max) 列については、特定の列に格納できるデータの最大サイズが 2 GB に制限されません。特定の列の最大サイズは無制限です。つまり、7 GB もある X 線写真のような医療画像でも、通常の SQL Server テーブルの列に格納できます。FILESTREAM データは SQL Server Express Edition データベースの 4 GB という最大サイズ制限に含まれないので、SQL Server 2008 Express Edition で BLOB にも使用できます。

API の説明を始める前に、強調しておくことがあります。つまり、いったん SQL Server の FILESTREAM 記憶域を使用してファイルデータを格納したら、SQL Server の制御の範囲外でそのデータにアクセスしたり、データを変更したりすることはできません。FILESTREAM のファイルが存在するディレクトリは、随時アクセス制御リスト (DACL) によって保護されており、SQL Server サービスアカウントおよびシステム管理者アカウントを含む Windows グループのみがアクセスを許可されます。そして、システム管理者は DACL を変更することでアクセスを削除できます。ユーザーがストリーミング API を使用してファイルを開こうとすると、データベース、スキーマ、テーブル、および列のレベルで従来の SQL アクセス許可についてのアクセスチェックが行われ、NTFS のアクセス許可は無視されます。notepad.exe (またはさらによくあるのは専用の写真編集プログラム) を使用して FILESTREAM データを直接編集すると、通常はデータベースが壊れます。ただし、SQL Server が提供するトランザクション対応のストリーミング API を使用すれば、SQL Server ベースの "トランザクション用メモ帳" プログラムを独自に作成できます。

Transact SQL を使用して FILESTREAM のプログラミングを行う

T-SQL での FILESTREAM のプログラミングは普通の T-SQL プログラミングとほぼ同じですが、いくつか注意点があります。まず、varbinary(max) WRITE メソッドを使用して FILESTREAM 列を部分的に更新することはできません。また、ストリーミング API には SQL Server で提供されるファイルパス名が必要なので (つまり、ストリーミング API は FILESTREAM 列の値が NULL ではない場合にのみ使用できます)、ファイル名を取得する唯一の方法は T-SQL を使用することです。NULL 値を FILESTREAM 列に挿入してもファイルは作成されませんが、NULL 以外の任意の値の INSERT を実行するとファイルが作成されます。FILESTREAM 列に対して UPDATE を実行すると、古いファイルが削除されて、代わりに新しいファイルが作成されます。行に対して DELETE 操作を実行すると、対応するファイルが削除されます。UPDATE または DELETE 操作で削除されたファイルは、ファイルシステムからすぐに消去されるのではないことに注意してください。ファイルの物理的な削除と領域の再利用には、ガベージコレクタスレッドが使用されます。

varbinary(max) で使用できる T-SQL の組み込み関数は、SUBSTRING、REPLACE、LEN、CHARINDEX などを含めてすべて FILESTREAM 列でも使用できます。FILESTREAM 記憶域は、データベーステーブルの列に対してのみ使用できます。変数、パラメータ (テーブル値パラメータを含む)、一時テーブル構造の列、およびテーブル値関数の戻り値には、FILESTREAM 属性を使用できません。また、FILESTREAM 属性は varbinary(max) 列でのみ使用できることにも注意してください。varchar(max) や XML などの他の大きいデータ型では FILESTREAM 属性を指定できません。文字データまたは XML データを FILESTREAM 記憶域に格納する場合は、列を varbinary(max) として指定し、CAST または CONVERT を使用してデータを文字または XML として処理する必要があります。

ストリーミング API を使用して FILESTREAM データにアクセスするには、最初に T-SQL を使用してパス名を取得する必要があります。それには、FILESTREAM 列に対して (大文字と小文字が区別される) PathName() メソッドを使用します。FILESTREAM の論理パスはバージョン管理されており、SQL Server 2008 で使用される Version 1 の形式では、パス名は同じ行の ROWGUIDCOL 列の値と結び付けられます (ただし、その列の値と等しくはありません)。ビューおよび派生テーブルでも FILESTREAM 列を使用できますが、PathName() メソッドを使用する必要がある場合は、ROWGUIDCOL を維持してください。たとえば、FILESTREAM と rowguid 列を含む T テーブルの場合は、図 2 のようなコードを作成します。

図 2 ビューを作成する

CREATE VIEW View1 
AS
SELECT RowGuidColumn , FileStreamColumn
FROM T;

SELECT FileStreamColumn.PathName() FROM View1;  -- works
GO

CREATE VIEW View2 
AS
SELECT FileStreamColumn FROM T;
GO

-- Fails because it is missing the RowGuidColumn
SELECT FileStreamColumn.PathName() FROM View2;
GO

最後に、FILESTREAM 列でデータの暗号化はサポートされていません。これは、EncryptByKey などのデータ暗号化 API だけでなく、SQL Server 2008 の透過的データ暗号化機能にも当てはまります。FILESTREAM 記憶域を含むデータベースで透過的データ暗号化を指定することはできますが、FILESTREAM ファイルは暗号化されません。

ファイル入出力を使用して FILESTREAM のプログラミングを行う

FILESTREAM 記憶域列でストリーミング入出力を使用するには、クライアント側にいくつかの前提条件があります。ストリーミング I/O を使用する場合は、ハンドルを開くときに SQL 資格情報を渡す手段がないので、統合セキュリティアカウントを使用する必要があります。FILESTREAM 記憶域は特殊なファイルシステムフィルタドライバを使用して実装されているので、FILESTREAM 記憶域を使用する列のプログラミングでは、すべての Win32 操作をサポートしているとは限らないファイルハンドルを使用します。ファイルハンドルを取得するネイティブの Win32 関数は OpenSqlFilestream です。この関数は SQL Native Client 10 DLL の一部であり、この DLL には SQL Server ODBC ドライバ、OLE DB プロバイダ、およびネットワークライブラリも含まれています。OpenSqlFilestream 関数は、Win32 ファイルハンドルのほとんどのストリーミング機能をサポートする Win32 ハンドルを返します。Win32 ファイルハンドルを取得するにはパス名といくつかの追加オプションが必要ですが、OpenSqlFilestream 関数には SQL Server だけが提供できる 2 つの情報が必要です。つまり、FILESTREAM 記憶域を使用する列で PathName() メソッドを呼び出すことによって返されるファイルの名前と、トランザクショントークンです。したがって、OpenSqlFilestream を使用するプログラミングでは、INSERT、UPDATE、または SELECT ステートメントは、それぞれ同等の 2 つの "SQL" ステートメント、つまり T-SQL ステートメントとストリーミングステートメントに分割されます。これらのステートメントをトランザクションで結び付ける必要があります。トランザクションとサポートされる分離レベルについては後でさらに詳しく説明しますが、ここでは、T-SQL 関数 GET_FILESTREAM_TRANSACTION_CONTEXT() を呼び出してトランザクショントークンを取得する必要があることだけを覚えておいてください。このトークンは、ファイルを開くユーザーと同じ Windows ユーザーのコンテキストで取得する必要があります。トランザクショントークンを取得する元の SQL ステートメントはトランザクションの一部である必要があることに注意してください。そうでないとトランザクショントークンは NULL になり、OpenSqlFilestream は失敗します。HANDLE を閉じるまでトランザクションをコミットすることはできません。特殊なファイルハンドルを使用してサポートされるファイルハンドル API は、ReadFile、WriteFile、TransmitFile、SetFilePointer、SetEndOfFile、および FlushFileBuffers です。他のファイル API を呼び出すと、ERROR_ACCESS_DENIED が返されます。特殊な HANDLE はメモリマップファイルをサポートしないことが明示されています。

SQL Server 2008 オンラインブックでは、ODBC と C++ を使用して OpenSqlFilestream により新しい行および FILESTREAM データを挿入する詳細な例が提供されています。

SELECT ステートメントでは、PathNames とトランザクショントークンに対して行うデータベースへのラウンドトリップは 1 回だけです。INSERT または UPDATE ステートメントでも、データベースラウンドトリップを 1 回だけにすることができます。これらのステートメントについては、SQL Server 2005 で導入された T-SQL OUTPUT 句が役に立ちます。1 行を処理し、必要なすべての情報を 1 回のラウンドトリップで取得する UPDATE ステートメントを次に示します。

UPDATE dbo.Employees2 
SET name = 'NewName' WHERE id = 8
OUTPUT inserted.photo.PathName(),
       GET_FILESTREAM_TRANSACTION_CONTEXT()

行を削除するとファイルも削除されるので、DELETE ステートメントの使用については説明しません。ストリーミング入出力を使用して DELETE を実行することはできません。ただし、INSERT または UPDATE を使用した BLOB の読み書きに関しては、いくつかのことを理解しておく必要があります。さらに、BLOB の更新を 2 つの場合に分けて説明します。完全な置換 (書き換え) の場合と、部分的な更新の場合です。

BLOB を含む行の INSERT を使用した挿入は、ストリーミング入出力の使用が最適となる理由の 1 つです。SQL Server API は varbinary(max) 列を使用するストリーミング入力をサポートしていませんが、T-SQL の STUFF 関数または WRITE メソッドを使用することで、データを分割して書き込むことができます (FILESTREAM 記憶域を使用するときに WRITE メソッドは使用できないことを思い出してください)。INSERT の興味深い点は、NULL 値を挿入するとファイルが作成されないことです。PathName() メソッドも NULL を返し、データをストリーミングするためのファイルはないということになります。INSERT を使用するには、NULL 値ではなく空の文字列を挿入し、パス名を取得して、コンテンツを空のファイルにストリーミングします。T-SQL ステートメントは次のようになります。

INSERT dbo.Employees2 (id, ... photo)
VALUES(1, ... CAST('' as VARBINARY(MAX))
OUTPUT inserted.photo.PathName(),GET_FILESTREAM_TRANSACTION_CONTEXT()

その後、書き込み用にファイルを開き、データをストリーミングできます。完成した置換 UPDATE は、INSERT と同じように動作します。FILESTREAM ではない列を更新して、パス名とトランザクショントークンを取得し、ファイルハンドルを通してデータをストリーミングします。FILESTREAM 記憶域の列に既にデータが含まれることがわかっている場合以外は、T-SQL の更新ステートメントでデータを空の文字列に設定することをお勧めします。

FILESTREAM 列の部分的な更新は、更新を行う前にファイルの情報を読み取ることが必要になる場合があるので、もう少し処理が複雑です。これを行うには、ハンドルと FSCTL_SQL_FILESTREAM_FETCH_OLD_CONTENT パラメータを指定した DeviceIoControl 関数を使用できます。この関数を呼び出すと、ファイルの内容のサーバー側コピーが作成されます。この呼び出しを実行した後、ReadFile は、End Of File を返すまで、適切なデータを返します。この方法で読み取りと更新を行う場合、高パフォーマンスのアプリケーション、特に SQL Server と同じマシンから FILESTREAM にアクセスする可能性のあるアプリケーションでは、重複した入出力を使用することをお勧めします。大量の部分更新を行う必要がある場合は、FILESTREAM 記憶域を使用すると、FILESTREAM 記憶域を使用しない SQL Server の varbinary(max) を使用する場合に比べて処理がかなり遅くなることに注意してください。

SqlFileStream .NET データ型

.NET プログラムでは、通常、Win32 ファイルハンドルを扱う必要はありません。PInvoke (プラットフォームコード呼び出し) と呼ばれる技法を使用すると .NET プログラムで OpenSqlFilestream を使用できますが、OpenSqlFilestream 関数とファイルハンドルアクセスを .NET クラスにカプセル化する方が便利です。.NET Framework 3.5 SP1 では、System.Data.Types.SqlFileStream クラスがこの目的を満たします。使い方はほとんど同じです。SqlFileStream のコンストラクタには、パス名とトランザクショントークンおよびいくつかのオプションを渡す必要があります。このコラムに付属するコードサンプルでは、SqlFileStream を使用して行の INSERT を行う方法が示されています。

SqlFileStream オブジェクトは System.IO.Stream から派生し、使い方は "普通の" .NET ストリームと同じです。SqlFileStream API と OpenSqlFilestream Win32 関数の使用上の重要な違いは、SqlFileStream は既定のバッファサイズである 4K を使用し、OpenSqlFilestream のハンドルは使用しないということです。また、SqlFileStream を ReadWrite モードで使用すると、DeviceIoControl の呼び出しが自動的に行われるので便利です。ネイティブ API はこれをサポートせず、"部分更新" パターンでは DeviceIoCtrl を明示的に呼び出す必要があります。SqlFileStream データ型を使用するには、.NET 3.5 SP1 をクライアントまたは Web サーバーにインストールする必要があります。

FILESTREAM とトランザクション

前に説明したように、単にファイル名を SQL Server に格納し、ファイルをファイルシステムに格納する代わりに FILESTREAM 記憶域を使用する利点の 1 つは、データのトランザクション一貫性が保証されることです。Transact SQL で行を挿入し、ストリーミング API を使用してファイルを挿入した場合は、操作全体が成功するか、または操作全体が失敗します。ファイル名に対応するファイルが存在しなかったり、対応するエントリが SQL Server にない孤立したファイルシステムアイテムが作成されたりする可能性はありません。OpenSqlFilestream API では、これを保証するために、ストリーミング API を使用するときは常に有効なトランザクションが開かれている必要があります。ただし、SQL Server では、さまざまなトランザクション分離レベル、およびロックとバージョン管理という 2 つの異なるトランザクションセマンティクスがサポートされます。SQL Server のロックマネージャはファイルシステムロックを管理しません。では、ストリーミング API はすべての分離レベルでどれだけ適切に動作するのでしょうか。

ストリーミングを使用するときは、アトミック操作が 2 つの異なる SQL ステートメントで構成されていると考えると理解しやすくなります。つまり、T-SQL 部分のステートメントと、ストリーミング部分のステートメントです。トランザクショントークンを取得するには、T-SQL の部分を最初に実行する必要があります。T-SQL コマンドを実行する前に、ADO.NET の SqlConnection.BeginTransaction メソッドまたは System.Transactions の TransactionScope を使用して、明示的なトランザクションを開始する必要があります。手動および自動のトランザクション管理用の類似メソッドが ODBC などの他の API にあります。ファイルハンドルを閉じるまで、トランザクションを開いた状態に保つ必要がありますSqlTransaction.Save の呼び出しは、ファイルハンドルを開いている間は実行できず、実行するとトランザクションをコミットできなくなります。SqlTransaction.Rollback を呼び出すと、ファイルが開かれている場合であっても、トランザクションはロールバックされます。ファイルハンドルを閉じるときにトリガが起動されます。

ストリーミング API と FILESTREAM 記憶域は 4 つのロックトランザクション分離レベルのすべてで使用できますが、ストリーミングアクセスのセマンティクスは常に Read Committed と同様です。Read Committed 分離レベル (既定値) を使用すると、ファイルが読み取り用に開かれている場合、他の読み取りはファイルを読み取ることができ、書き込みはブロックされます。ファイルが読み取り用に開かれている場合は、トランザクションが終了するまでブロックされたままになります。Read Uuncommitted 分離レベルは許可されますが注意が必要です。つまり、通常の Read Uuncommitted の動作では新しい提案バージョンのファイルが読み取られますが、ファイルの更新が進行中の場合は、Read Uuncommitted トランザクションで古いバージョンのファイルが読み取られます。ファイルのストリーミングを使用するときの反復可能な読み取りおよびシリアル化可能な動作は、データベースで行がロックされている場合と同じです。

バージョン管理分離レベル、つまり Read Committed スナップショット分離およびスナップショットトランザクションは、FILESTREAM を使用するデータベースでは許可されません。これは、FILESTREAM 列を含むテーブルだけではなく、データベース全体についても同じです。Read Committed スナップショット分離およびスナップショットトランザクションを有効にする ALTER DATABASE ステートメントは、FILESTREAM 記憶域が存在する場合は失敗します。

FILESTREAM での機能の相乗効果

FILESTREAM は、トランザクションログのオーバーヘッドとデータベースの断片化を発生させることなく大きいデータをデータベースに格納するのに便利ですが、データの一部分を永続的な計算列に取り出す場合にも役に立ちます。これにより、ファイルをまったく読み取ることなく、BLOB のプロパティに対するクエリを実行できます。たとえば、JPEG 形式の写真を格納してあり、背景色や写真の縦と横などのカラーテーブルの一部分を、分けて格納するとします。このような場合は、varbinary(max) 列のその部分に永続的な計算列を定義するだけで済みます。データは行に格納されます。前に定義した Employees2 テーブルを使用した例は、次のようになります。

ALTER TABLE dbo.Employees2
  ADD PhotoWidth AS dbo.ExtractWidth(Photo) PERSISTED;
A SQL query to obtain the photo width does not need to access the file at all:
SELECT Id, Photo 
FROM dbo.Employees2
WHERE PhotoWidth > 1200;

ただし、varbinary 型の永続的な計算列にはインデックスを作成できないことに注意してください。

SQL Server のフルテキストインデックスと FILESTREAM 記憶域でのフルテキスト検索の組み合わせは、機能の相乗効果の適例です。フルテキスト検索フィルタコンポーネントは Microsoft Office ドキュメント、PDF ファイル、テキストファイルなどのドキュメントタイプごとに存在し、FILESTREAM 記憶域を使用するとこれらのファイルをデータベースではなくファイルシステムに格納できます。具体的な例として、エラーログまたは Web ログファイルのコピーを FILESTREAM 記憶域の列に格納し、列のフルテキストインデックスを作成できます。SQL Server 2008 では、フルテキスト検索はインプロセスで実行するので、検索サービスをプロセス外で呼び出す必要はありません。次のようなクエリはインプロセスで動作するので非常に高速です。

SELECT id, Abstract 
FROM error_logs 
WHERE CONTAINS(ErrorText, 'unhandled');

この記事の最初で、FILESTREAM 記憶域は統合されたバックアップと復元だけでなく、SQL データとファイルデータの間のトランザクションの一貫性も提供すること、ただし FILESTREAM 記憶域が使用できるのはローカルディスクストレージだけであることを指摘しました。必要な機能がトランザクションの一貫性だけであり、ファイルをリモートサーバーまたはコンテンツアドレス指定可能なストレージに置きたい場合は、SQL Server 2008 の付随機能であるリモート BLOB ストレージ (RBS) があります。この機能は、SQL Server 2008 Feature Pack の一部として無料でダウンロードして利用できます。RBS は、トランザクション操作を可能にする API と、データベーステーブルでの BLOB ポインタ、BLOB のガベージコレクション、およびトランザクションへの参加を処理するための一連のストアドプロシージャで構成されています。コンテンツアドレス指定可能ストレージのベンダーからは、独自のハードウェア用のドライバが提供されています。NTFS ファイルシステム用の RBS ドライバのサンプルは CodePlex からダウンロードでき、EMC からは Centera コンテンツアドレス指定ストレージシステム用の RBS プロバイダがリリースされています。RBS の API と FILESTREAM の API には類似性はありませんが、将来的には調整される可能性があります。

まとめると、FILESTREAM 記憶域を使用すると、大きい BLOB をファイルとしてファイルシステムに格納し、T-SQL ステートメントまたはトランザクションストリーミング API を使用してアクセスできます。この機能を利用すれば、ストリーミングのパフォーマンスが向上するだけでなく、大きい BLOB に関するデータベースの完全な統合を実現できます。

ご質問やご意見は、Bob (mmdbdev@microsoft.com) まで英語でお送りください。

Bob Beauchemin は、データベース指向アプリケーションの専門家およびアーキテクト、学習コースの作成者および教官、ライター、および SQLskills のデベロッパースキルパートナーです。これまで、SQL Server、データアクセスおよび統合のテクノロジ、およびデータベースセキュリティについてさまざまな書籍や記事を執筆しています。連絡先は bobb@sqlskills.com です。

次の方法で共有

その他のリソース