SharePoint の内部SharePoint の外部ストレージ ソリューションを作成する

Pav Cherny

コードのダウンロード: ChernySharePoint2009_06.exe(2,006 KB)

目次

内部バイナリ ストレージ
外部バイナリ ストレージ
アンマネージ EBS プロバイダを作成する
マネージ EBS プロバイダを作成する
EBS プロバイダを SharePoint に登録する
ガベージ コレクションを実装する
まとめ

マイクロソフトでは、Microsoft Windows SharePoint Services (WSS) 3.0 および Microsoft Office SharePoint Server (MOSS) 2007 のコンテンツ データベースに格納されているデータの 80% は、Microsoft Office Word 文書、Microsoft Office Excel ワークシート、Microsoft Office PowerPoint プレゼンテーションなどの非リレーショナル バイナリ ラージ オブジェクト (BLOB) データであると見ています。リレーショナル メタデータはわずか 20% に過ぎず、データベース バックエンドで Microsoft SQL Server リソースが最適な状態で使用されていないことが伺われます。SharePoint では、SQL Server 2008 で導入された、FILESTREAM 属性やリモート BLOB ストレージ API など、非構造化データ向けの SQL Server の革新的な最新技術は利用していませんが、膨大なデータの保存効率と管理性を高める独自のオプションを提供しています。

具体的には、SharePoint には外部バイナリ ストレージ プロバイダ API である ISPExternalBinaryProvider が含まれています。これは、最初 2007 年 5 月に修正プログラムとして公開されたもので、その後サービス パック 1 に組み込まれました。この ISPExternalBinaryProvider API は、リモート BLOB ストレージ API とは異なります。サードパーティ ベンダは、この API を使用して、SharePoint を CAS (content-addressable storage) システムなどの高度なストレージ ソリューションと統合できます。また、SharePoint ファーム内の保存効率とスケーラビリティを高めるカスタム ソリューションを構築する場合は、コンテンツ データベース外の中央のファイル サーバーに格納されている SharePoint の BLOB データのメンテナンスに、この API を使用することもできます。ただし、この API は WSS 3.0 と MOSS 2007 固有の API であることに注意してください。この API は次期リリースの SharePoint で変更される予定であるため、そのときにはプロバイダを更新する必要があります。

このコラムでは、ISPExternalBinaryProvider API を使用して SharePoint の記憶域アーキテクチャを拡張する方法、そのメリットとデメリット、実装の詳細、パフォーマンス上の考慮事項、ガベージ コレクションなどについて説明します。また、インターフェイスが正しく実装されているにもかかわらず、ISPExternalBinaryProvider マネージ コンポーネントが SharePoint に読み込まれない原因となる Microsoft Visual Studio の 64 ビットの互換性の問題についても説明します。必要に応じて、WSS 3.0 SDK に収録されている ISPExternalBinaryProvider ドキュメントも紹介します。それ以外の参考資料としては、Kyle Tillman のブログがお勧めです。

Kyle のブログではマネージ コードの実装の課題に対応する方法についてとても詳しく説明していますが、WSS 3.0 SDK と Kyle のブログのどちらも Visual Studio のサンプル プロジェクトは提供されていないため、このコラム付属リソースにアンマネージとマネージの両方の ISPExternalBinaryProvider サンプル コードを含めました。これらのサンプルは、外部ストレージ ソリューションと SharePoint との統合に興味がある方の、足がかりとしてご利用いただければさいわいです。ただし、これらのサンプルはテストを行っていないため、運用環境で使用できる状態のものではないことに、ご注意ください。

内部バイナリ ストレージ

既定で、SharePoint では BLOB データをコンテンツ データベースの AllDocStreams テーブルの Content 列に格納します。この方法の明らかなメリットは、リレーショナル データとそれに関連付けられた非リレーショナルなファイル コンテンツ間で、トランザクションの整合性が確実に保たれることです。たとえば、Word 文書のメタデータを非構造化コンテンツと併せてコンテンツ データベースに挿入することも、選択、更新、または削除操作において、メタデータと対応する非構造化コンテンツを関係付けることも難なく実行できます。ただし、この既定の方法の最も明らかなメリットは、記憶域リソースを効率的に使用できることです。I/O サブシステムは高いパフォーマンスを実現するように最適化されていますが、SQL Server のストレージ エンジンはファイル サーバーに完全に代わるものではありません。

図 1 に示すように、SQL Server データベースは、トランザクション ログとデータ ファイルで構成されています。信頼性の高いトランザクションの動作を実現するため、SQL Server は最初にすべてのトランザクション レコードをログ ファイルに書き込んでから、8 KB のページに格納されている対応データをディスク上のデータ ファイルにフラッシュします。選択している回復モデルによっては、バックアップを実行してトランザクション ログを削除しない限り、この処理のために BLOB データの 2 倍以上の記憶域が必要になります。また、SQL Server では SharePoint の非構造化コンテンツは直接データ ページに格納されません。SQL Server では、別個のテキスト/イメージ ページのコレクションが使用され、BLOB のルートへの 16 バイトのポインタがデータ行に格納されるだけです。このテキスト/イメージ ページは、バランス ツリーの形で編成されていますが、1 つのテーブルにはテキスト/イメージ ページのコレクションが 1 つしかありません。つまり、AllDocStreams テーブルの場合、すべてのファイルのコンテンツが、同じテキスト/イメージ ページのコレクション内に格納されます。1 つのテキスト/イメージ ページには、複数の BLOB データ フラグメントが保持される場合もありますし、32 KB を超える BLOB データの中間ノードが保持される場合もあります。

fig01.gif

図 1 SQL Server における既定の SharePoint BLOB データの格納状態

しかし、ここでは SQL Server の内部について深入りしないでおきましょう。要点は、SQL Server では非構造化コンテンツの読み取り時に、データ行を検索してテキストへのポインタを取得し、BLOB データのルート ノードと場合によっては他の中間ノードを検索して、複数のテキスト/イメージ ページに分散しているデータ フラグメントをすべて見つける必要があるということです。これらのフラグメントを SQL Server が完全にメモリに読み込まないと、すべてのデータ ブロックは取得されません。これは、SQL Server では I/O 操作がページ レベルで実行されるために起こる現象です。このような複雑な処理のために、ファイル ストリーミングのパフォーマンスは、ファイル システムを介する直接アクセスよりも劣ります。また、SQL Server では、image データ型の最大容量が 2 GB であるため、SharePoint のサイズも 2 GB に制限されます。AllDocStreams テーブルの Content 列は image 型の列であるため、SharePoint コンテンツ データベースに格納できるファイルのサイズは 2 GB に制限されます。

外部バイナリ ストレージ

ISPExternalBinaryProvider API を利用することで、SharePoint コンテンツ データベース内部の BLOB ストレージに代わる優れたソリューションを実現できます。この API は、StoreBinary および RetrieveBinary という 2 つのメソッドしか持たない単純な COM インターフェイスで、外部バイナリ ストレージ (EBS) プロバイダの実装に使用できます。アーキテクチャの詳細については、WSS 3.0 SDK の「外部 BLOB ストレージのアーキテクチャ」を参照してください。

ローカルの SPFarm オブジェクトの ExternalBinaryStoreClassId プロパティ (SPFarm.Local.ExternalBinaryStoreClassId) に EBS プロバイダの COM クラス識別子 (CLSID) を設定すると、SharePoint にプロバイダが読み込まれます。SharePoint にプロバイダが読み込まれると、ドキュメント ライブラリにファイルをアップロードするなど、BLOB データが送信されるたびにプロバイダの StoreBinary メソッドが呼び出されます。EBS プロバイダでは、関連付けられている外部ストレージ システムに BLOB データを格納して、対応する BLOB 識別子 (BLOB ID) を SharePoint に返すか、StoreBinary メソッドの pfAccepted パラメータを false に設定して BLOB を処理できなかったことを示します。後者の場合、SharePoint は通常どおり BLOB データをコンテンツ データベースに格納します。一方、EBS プロバイダで BLOB データを処理できた場合、SharePoint では BLOB ID のみを AllDocStreams テーブルの Content 列に挿入します ( 図 2 参照)。BLOB ID には、ファイル パス、グローバル一意識別子 (GUID)、コンテンツのダイジェストなど、EBS プロバイダによって外部ストレージ システムのコンテンツを特定できる任意の値を使用できます。たとえば、付属リソースのサンプル プロバイダでは、ファイル名に GUID を使用し、ファイル サーバー上で BLOB データを確実に識別できるようにしています。

fig02.gif

図 2 外部ストレージ システムへの SharePoint BLOB データの格納

SharePoint では、外部に保存されたファイルの DocFlags 列の値の最上位ビットを 1 に設定することで、ファイルを追跡しています。DocFlags は AllDocs テーブルの列の 1 つです。外部に保存されているファイルをユーザーが要求すると、SharePoint では DocFlags 列の値を確認し、AllDocStreams テーブルの Content の値を EBS プロバイダの RetrieveBinary メソッドに渡します。RetrieveBinary メソッドが呼び出されると、EBS プロバイダでは、指定された BLOB データを外部ストレージ システムから取得し、そのバイナリ コンテンツを ILockBytes インターフェイスを実装した COM オブジェクトの形で SharePoint に返します。ただし、SharePoint では、コンテンツ データベースに直接格納されている BLOB データについては、RetrieveBinary メソッドを呼び出しません。

また、ユーザーが SharePoint 経由で操作を行っている限り、この保存と取得のプロセスは、ユーザーには認識されません。したがって、組み込みの Web パーツを、リスト内のメタデータと外部に保存されているドキュメントを関連付けるカスタムの Web パーツに置き換える必要はありません。また、Microsoft Office などの生産性アプリケーション側で、メタデータとドキュメントが別々の場所に保存されるしくみを認識する必要はなく、検索操作でもメタデータとドキュメントを別々に処理する必要はありません。個人的にはこれが EBS プロバイダのアーキテクチャの一番のメリットだと考えていますが、ユーザーは SharePoint を経由して、外部に保存されている BLOB データにアクセスする必要があります。SharePoint を経由せずに、SQL Server 接続を介してコンテンツ データベースに直接アクセスすると、実際のファイル コンテンツではなく、BLOB ID がダウンロードされます (図 3 参照)。この動作は、テスト環境に SQL Download Web パーツ (2009 年 4 月号のコラムで SharePoint の AD RMS 保護をバイパスする方法の説明に使用したパーツ) を展開すると、確認できます。そのうえ、ユーザーには外部 BLOB ストアへのアクセス許可が不要です (付与しないようにします)。アクセスが必要なのは SharePoint のセキュリティ アカウントのみですが、これは SharePoint がサイトのアプリケーション プール アカウントのセキュリティ コンテキストを使用して EBS プロバイダのメソッドを呼び出すために必要なものです。

fig03.gif

図 3 EBS プロバイダを使用するとファイルのダウンロードに SharePoint アクセス許可が不要になる

ただし、EBS プロバイダには、SharePoint ファームのコンテンツ データベース内のメタデータと外部 BLOB ストアの整合性の維持が複雑というデメリットがあることに注意してください。EBS プロバイダのメリットとデメリットの詳細な説明については、WSS 3.0 SDK の「操作上の制限とトレードオフ分析」を参照してください。これは非常に重要なトピックなので、EBS プロバイダを SharePoint 環境に実装する前に、必ずお読みください。

アンマネージ EBS プロバイダを作成する

では、EBS プロバイダの作成に取りかかりましょう。ISPExternalBinaryProvider インターフェイスについては、WSS 3.0 SDK の「BLOB アクセス インターフェイス: ISPExternalBinaryProvider」に詳しい説明があります。ただし、EBS プロバイダについての詳細情報は提供されていませんが、EBS プロバイダを作成するには、既存の COM サーバーのインターフェイスを利用する以上の作業が必要です。自分たちで COM サーバーを作成し、ISPExternalBinaryProvider インターフェイスを実装する必要があります。最も重要なのは、WSS 3.0 SDK のドキュメントでは、作成する COM サーバーの種類と必要なスレッド モデルについて触れられていないことです。従来の COM サーバーは、アウトプロセスでもインプロセスでも実行でき、シングルスレッド アパートメント (STA) モデル、マルチスレッド アパートメント (MTA) モデル、STA と MTA の両方に対応するモデル、またはフリー スレッド モデルをサポートすることができました。しかし、EBS プロバイダが適切に機能するには、STA と MTA の両方に対応するスレッド モデルをサポートするスレッド セーフのインプロセス COM サーバーを作成する必要があります。

また、使用するプログラミング言語についても、検討する必要があります。これは、ISPExternalBinaryProvider インターフェイスが SharePoint の最下位の API であるため、重要です。パフォーマンスの問題は、SharePoint ファーム全体に及ぶ可能性があります。このため、Visual C++ や Active Template Library (ATL) など、小さくて処理の速い COM オブジェクトを作成できる言語を使用することをお勧めします。ATL では、スレッド セーフな COM サーバーをアンマネージ コードで容易に開発できる、便利な C++ クラスを提供しています。これらのクラスを利用すれば、スレッドが適切なレベルでサポートされます。

また、Visual Studio には、さまざまな ATL ウィザードが用意されています。操作は簡単で、ATL プロジェクトを作成し、目的のサーバーの種類のダイナミックリンク ライブラリ (DLL) を選択します。作成した ATL プロジェクトのインターフェイス定義言語 (IDL) に WSS 3.0 SDK に収録されている ISPExternalBinaryProvider インターフェイスの定義をコピーし、ATL シンプル オブジェクトに新しいクラスを追加します。スレッド モデルを "両方" に指定し、アグリゲーションはなしにします。新しいクラスを右クリックして [追加] をポイントし、[インターフェイスの実装] をクリックして、[ISPExternalBinaryProvider] をクリックします。必要な操作は、これだけです。インターフェイス実装ウィザードによって必要なプラミングがすべて実行されるため、StoreBinary メソッドと RetrieveBinary メソッドの実装に集中できます。

アンマネージの C++ コードだからといって、恐れることはありません。付属リソースの SampleStore.cpp ファイルを分析すると、StoreBinary メソッドと RetrieveBinary メソッドの実装は比較的単純であることがわかります。基本的に、サンプルの StoreBinary メソッドでは、StorePath レジストリ値、SharePoint から渡されたサイト ID、および BLOB データの GUID を基にファイル パスを組み立て、Win32 の WriteFile 関数を使用して ILockBytes インスタンスから取得したバイナリ データを保存します。一方、サンプルの RetrieveBinary メソッドでは、同じ StorePath レジストリ値、サイト ID、および SharePoint から渡された BLOB ID を基にファイル パスを組み立て、Win32 の ReadFile 関数を使用して非構造化データを取得します。EBS プロバイダは、このデータを新しい ILockBytes インスタンスに渡し、このインスタンスからデータが SharePoint に返されます。図 4 に、EBS プロバイダがファイル パスを組み立てる方法を示します。

fig04.gif

図 4 サンプルの EBS プロバイダによる StoreBinary メソッドと RetrieveBinary メソッドの操作のためのファイル パスの組み立て

マネージ EBS プロバイダを作成する

COM の相互運用機能に伴う複雑さのために、アンマネージ プロバイダを作成するよりもマネージ EBS プロバイダを作成する方が複雑になるとしても、SharePoint 開発者は、使い慣れたマネージ言語を使用して EBS プロバイダを作成する方を好む場合もあるでしょう。アンマネージ コードで記述されたアプリケーションでは、単一のバージョンの共通言語ランタイム (CLR) しか読み込むことができないため、コードでは SharePoint の他のコンポーネントが使用しているのと同じバージョンの CLR を使用する必要があることに注意してください。バージョンが異なると、予期しない動作をする可能性があります。また、アンマネージ インターフェイスとそれに対応するパラメータやバッファのマーシャリングを処理する必要もあります。付属リソースの SampleStore.cpp と SampleStore.cs を比べてみてください。コードの構造やプログラミングの簡単さという点では、マネージ言語を使用するメリットはありません。

さらに、x64 プラットフォームでマネージ EBS プロバイダを開発する場合は、64 ビットの互換性の問題についても注意が必要です。図 5 は、開発コンピュータでの無効な COM 登録の設定に起因する一般的なエラーを示しています。Visual Studio 2005 または Visual Studio 2008 で、プロジェクトのプロパティの [COM の相互運用機能に登録] チェック ボックスをオンにすると、レジストリの HKEY_CLASSES_ROOT\Wow6432Node\CLSID\<プロバイダの CLSID> にプロバイダの COM 登録が設定されます。Visual Studio では、x64 プラットフォーム上でも、32 ビット版のアセンブリ登録ツール (Regasm.exe) が使用されます。

fig05.gif

図 5 無効な COM 登録設定のため、マネージ EBS プロバイダが読み込まれない

ただし、64 ビット版の SharePoint では、Wow6432Node に登録されている 32 ビットの COM サーバーを読み込むことができないため、%WINDIR%\Microsoft.NET\Framework64\v2.0.50727 ディレクトリにある 64 ビット版の Regasm.exe を使用して、手動でマネージ EBS プロバイダを登録する必要があります。たとえば、「%WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe」というコマンドを実行すると、ManagedProvider.dll によって、HKEY_CLASSES_ROOT\CLSID\<プロバイダの CLSID> に、必要なマネージ サンプル プロバイダの登録設定が作成されます。または、セットアップ プログラムを作成して、EBS プロバイダが自動的に COM 登録されるように設定することもできます。

また、マネージ EBS プロバイダの場合は、アンマネージの ATL プロバイダに比べて、格段に多くのオーバーヘッドが発生し、パフォーマンスが劣ることに注意してください。これは、レジストリの COM 登録設定を比べるとわかります。InProcServer32 キーの値からわかるように、アンマネージ EBS プロバイダの DLL は COM ランタイムによって直接読み込まれますが、マネージ EBS プロバイダの場合は CLR のコア エンジンである Mscoree.dll がインプロセス サーバーとして利用されます。したがって、マネージ EBS プロバイダの場合、COM ランタイムによって、まず CLR が読み込まれます。次に CLR によって、Assembly キーに登録されている EBS プロバイダのアセンブリを読み込み、COM 呼び出し可能ラッパー (CCW) プロキシを作成して、アンマネージの SharePoint クライアント (Owssvr.dll) とマネージ EBS プロバイダ間の対話を処理します。

アンマネージの SharePoint サーバーは、マネージ EBS プロバイダと直接対話しないことに注意してください。パラメータのマーシャリング、マネージ メソッドの呼び出し、HRESULT の処理は、CCW によって行われます。この間接的な処理は、マネージ メソッドの戻り値とアンマネージ メソッドの戻り値の型を比べて違いを見ると、特によくわかります。アンマネージ メソッドでは HRESULT を返して成功または失敗を示しますが、マネージ メソッドでは戻り値に void を使用する必要があります。したがって、マネージ コードでは明示的な HRESULT は返しません。エラー状態が発生した際には、システムまたはユーザー定義の例外を返す必要があります。マネージ メソッドが例外を返すことなく完了した場合、CCW では自動的に S_OK をアンマネージ クライアントに返します。

一方、マネージ メソッドで例外が発生した場合、CCW ではエラー コードとエラー メッセージを HRESULT とエラー情報にマップします。このため、CCW には ISupportErrorInfo や IErrorInfo など、さまざまなエラー処理インターフェイスが実装されていますが、SharePoint ではこのようなインターフェイスが利用されません。EBS プロバイダでは、Windows イベント ログ、SharePoint 診断ログ、トレース ファイルなどを利用して、独自のエラー レポート機能を実装する必要があります。SharePoint で対応できるのは、S_OK (成功した場合) および E_FAIL (エラーの場合) という HRESULT 値のみです。E_FAIL を SharePoint に返すには、Marshal.ThrowExceptionForHR メソッドを使用できます (SampleStore.cs 参照)。

EBS プロバイダを SharePoint に登録する

WSS 3.0 SDK の ISPExternalBinaryProvider に関するセクションのうち、最もわかりづらいのは、「BLOB プロバイダをインストールおよび構成する」でしょう。本稿執筆時点では、このセクションには間違った理解につながる情報と誤った情報が含まれています。Windows PowerShell コマンドさえも間違っています。EBS プロバイダを $yourProviderConfig 変数に代入後、$providerConfig.ProviderCLSID を使用した場合に、$providerConfig 変数が存在しないというエラーが返されても驚かないでください。Active プロパティと ProviderCLSID プロパティは、ISPExternalBinaryProvider インターフェイスに含まれていないため、$providerConfig 変数にアクセスできなくて当然です。これらの不思議なプロパティは、このセクションで取り上げられていないデュアル インターフェイスのプロパティです。遊び心から、マネージ コードとアンマネージ コードの両方でサンプルを実装してみましたが、実際の ISPExternalBinaryProvider インターフェイスの実装には、これらの特別なプロパティはまったく必要ありません。

ProviderCLSID プロパティは便利な場合もありますが、UnmanagedProvider.SampleStore や ManagedProvider.SampleStore など、ProgID を検索すると、CLSID はレジストリでも見つかります。また、コード ファイルの SampleStore.rgs と SampleStore.cs にも CLSID が含まれています。前述のとおり、ローカルの SPFarm オブジェクトの ExternalBinaryStoreClassId プロパティに CLSID を設定すると、EBS プロバイダが登録されます。ローカルの SPFarm オブジェクトの ExternalBinaryStoreClassId プロパティに 空の GUID ("00000000-0000-0000-0000-000000000000") を設定すると、EBS プロバイダの登録が解除されます。必ず SPFarm オブジェクトで Update メソッドを呼び出して、構成データベースに変更を保存し、インターネット インフォメーション サービス (IIS) を再起動してください。次のコードは、Windows PowerShell を使用してこれらの作業を実行する方法の一例です。

[System.Reflection.Assembly]::LoadWithPartialName('Microsoft.SharePoint')
$farm = [Microsoft.SharePoint.Administration.SPFarm]::Local

# Registering the CLSID of an EBS provider
$farm.ExternalBinaryStoreClassId = "C4A543C2-B7DB-419F-8C79-68B8842EC005"
$farm.Update()
IISRESET

# Removing the EBS provider registration
$farm.ExternalBinaryStoreClassId = "00000000-0000-0000-0000-000000000000"
$farm.Update()
IISRESET

ガベージ コレクションを実装する

他の不思議なコンポーネントと重要なコード スニペットについて述べられている WSS 3.0 SDK のセクションとしては、「レイジー ガベージ コレクションを実装する」があります。本稿執筆時点では、このセクションには、また別の不思議な DirFromSiteId メソッドと FileFromBlobid メソッドを使用した Utility クラスへの参照と、Directory.GetFiles メソッドの結果を FileInfo 配列に格納するという誤った割り当ての情報が含まれていますが、WSS 3.0 SDK ドキュメントの品質に多くを求めすぎないことにしましょう。DirFromSiteId および FileFromBlobid ヘルパ メソッドは、名前から機能がわかりますし、FileInfo 配列を使用するという不適切な情報は、単に文字列配列を使用するようにすれば問題ありません。また、Directory.GetFiles メソッドは DirectoryInfo オブジェクトの GetFiles メソッドの呼び出しに置き換えることができます。付属リソースの Garbage Collector サンプル プログラムでは、DirectoryInfo オブジェクトを使用する方法を採用していますが、手順はドキュメントに記載されているガベージ コレクションの実装手順に従っています。

SDK の説明からそれますが、Garbage Collector サンプルで重要な点の 1 つは、処理タイミングの対処です。処理のタイミングによっては、ガベージ コレクション中に有効なファイルが誤って識別および削除される可能性があるため、これは非常に重要な問題です。図 6 を参照してください。これは、WSS 3.0 SDK で推奨されている孤立したファイルの特定方法を示しています。まず EBS ストア内の全 BLOB ファイルを列挙し、サイトの ExternalBinaryIds コレクションを利用して、コンテンツ データベースに存在している参照を特定して、特定した参照をすべて BLOB ファイルの一覧から削除しています。その結果 BLOB ファイルの一覧に残った参照から、削除する必要がある孤立ファイルを特定できます。

fig06.gif

図 6 処理のタイミングによって、誤って孤立ファイルとして認識された有効な BLOB

ただし、当然のことながら、EBS プロバイダでは、まず BLOB データの書き込みを完了しないと、BLOB ID を SharePoint に返すことはできません。ネットワーク帯域幅などの影響で、I/O のパフォーマンスは変動します。そのため、EBS プロバイダが新しい BLOB データを作成した (これは作成された時点で BLOB ファイルの一覧に追加されます) が、BLOB データの書き込みは、ExternalBinaryIds コレクションを特定した後に完了したために、このコレクションには BLOB ID は含まれていないという状態が発生することもあり得ます。その結果、新しい BLOB データは孤立ファイルとして BLOB ファイルの一覧に表示され、この時点で孤立ファイルとして認識された BLOB データを削除すると、誤って有効なコンテンツ アイテムが削除され、データが失われます。この問題を避けるため、Garbage Collector サンプル プログラムでは、ファイルの作成時刻を確認し、1 時間以上前に作成されたアイテムのみを BLOB ファイルの一覧に追加するようにしています。

まとめ

外部ストレージ ソリューションを SharePoint と統合することで、SharePoint ファームの保存効率、システム パフォーマンス、およびスケーラビリティを向上できます。また、ユーザーによる非構造化コンテンツへのアクセスを SharePoint 経由のアクセスに制限できることも、メリットの 1 つです。SQL Server に直接接続して、コンテンツ データベースからデータを取得した場合、取得されるのは、実際のファイルではなく、バイナリの BLOB 識別子 (BLOB ID) です。ただし、EBS プロバイダには、SharePoint ファームのコンテンツ データベース内のメタデータと外部 BLOB ストアの整合性の維持が複雑というデメリットがあります。

SharePoint と外部ストレージ ソリューションを統合するには、EBS プロバイダを作成する必要があります。EBS プロバイダは、StoreBinary および RetrieveBinary という 2 つのメソッドを持つ ISPExternalBinaryProvider インターフェイスを実装した COM サーバーです。EBS プロバイダはアンマネージ コードとマネージ コードのどちらでも作成できますが、マネージ コードを使用する場合は、パフォーマンスと互換性の問題に注意してください。また、ISPExternalBinaryProvider インターフェイスには DeleteBinary メソッドが含まれていないことにも注意してください。孤立した BLOB データは、レイジー ガベージ コレクションによって、明示的に削除する必要があります。その際には、有効な BLOB アイテムを誤って削除しないように、処理のタイミングに十分注意してください。

Pav Cherny は、主にコラボレーションとユニファイド コミュニケーションに関するマイクロソフト テクノロジを扱う IT 専門家であり、IT 関連書籍の執筆も行っています。これまでに、IT の運用とシステム管理についてのホワイト ペーパー、製品マニュアル、書籍などを執筆してきました。Pav は、ドキュメント管理とローカライズ サービスの専門企業 Biblioso Corporation の代表取締役です。