內部 SharePoint 建立外部儲存方案的 SharePoint

Pav Cherny

可在程式碼下載： ChernySharePoint2009_06.exe(2,006 KB)

內容

內部二進位的存放裝置
外部的二進位碼存放
建立一個 Unmanaged 的 EBS 提供者
建立受管理的 EBS 提供者
在 SharePoint 中註冊的 EBS 提供者
實作記憶體回收
結論

Microsoft Office Word 文件]、 [Microsoft Office Excel 試算表和 [Microsoft Office PowerPoint 簡報等的非關聯式二進位大型物件 (BLOB) 資料多達 80 %的資料儲存在 Microsoft Windows SharePoint Services (WSS) 3.0 和 Microsoft Office SharePoint Server (MOSS) 2007 內容資料庫的 Microsoft 估計。 表示不理使用 Microsoft SQL Server 的資源，在資料庫後端的關聯式繼資料 (只有 20 %。 SharePoint 會不會利用最近的非結構化資料，例如 FILESTREAM 屬性 (Attribute) 或遠端的 BLOB 儲存 API，介紹 SQL Server 2008 的 SQL 伺服器創新的但提供自己選項增加儲存效率與大量的資料磁碟區的管理性。

特別，SharePoint 包含提供的外部的二進位儲存者 API 的 Microsoft 第一次發行的 Hotfix 可能 2007 的 ISPExternalBinaryProvider 和 Incorporated 到 Service Pack 1 的更新版本。 ISPExternalBinaryProvider API 是分開遠端 BLOB 存放裝置 API。 協力廠商可以使用這個的 API 整合等可定址的內容儲存區 (CAS) 系統進階的儲存解決方案，SharePoint。 您也可以使用這個 API，來維護 SharePoint BLOB 資料，在中央檔案伺服器以外的內容資料庫上，如果您要建置自訂解決方案來提升儲存效率和延展性，在 SharePoint 伺服器陣列中。 請記住，但是，此 API WSS 3.0 與 MOSS 2007 特定。 它將會在下一意味著您必須更新您的提供者的 SharePoint 版進行變更。

此的資料行中我將討論如何擴充 SharePoint 儲存架構使用 ISPExternalBinaryProvider API，包括優點和缺點，實作詳細資料、 效能的考量以及記憶體回收。 我也會討論 64 位元的相容性的 Microsoft Visual Studio 可能會造成無法載入 SharePoint 管理 ISPExternalBinaryProvider 儘管一個正確的介面實作的元件。 在適當，我請參閱 ISPExternalBinaryProvider 文件在 WSS 3.0 SDK 中。 另一個值得一提的參考 Kyle Tillman 部落格.

Kyle 會很好，說明如何，他精通在實作上，在 Managed 程式碼，但不是 WSS 3.0 SDK 或 Kyle 的部落格內容會包含 Visual Studio 範例專案，因此我決定提供 ISPExternalBinaryProvider 於這個資料行的小幫手] 內容的 Unmanaged 和 Managed 程式碼的範例。 這些範例的目的是協助您開始如果您有興趣就能整合 SharePoint 外部儲存解決方案中。 記住，這些範例是未經測試，無法準備生產環境使用。

內部二進位的存放裝置

預設的情況下，SharePoint 會將 BLOB 資料儲存在內容資料庫中 AllDocStreams 資料表的內容的資料行中。 這個方法的明顯優點將是您，關聯式資料] 和 [非關聯式相關聯的檔案內容之間的簡單交易的一致性。 例如，它不是複雜，用來將 Word 文件，以及與非結構化內容的中繼資料，插入在內容的資料庫，也不是關聯對應的非結構化內容，在選取，更新的中繼資料，或在刪除作業的複雜。 不過，最明顯的缺點，預設方法的都是存放資源的無效率使用。 雖然最佳化的高效能的 I / O 子系統，SQL Server 的儲存引擎不完全是伺服器檔案取代。

在 SQL Server 資料庫會組成交易記錄檔] 和 [資料檔案，如 [圖 1 ] 所示。 為了確保可靠的交易式行為，SQL Server 先寫入所有的交易記錄，記錄檔之前，它會清除 8KB 頁面中對應的資料，到磁碟上的資料檔案。 而在選取的復原模式，這需要兩倍以上 BLOB 的大小在儲存容量中直到您執行備份，並清除交易記錄檔。 此外，SQL Server 並不會直接在資料頁面中儲存非結構化的 SharePoint 內容。 而，SQL Server 會使用不同的文字 / 影像頁面集合，並只會儲存在資料列中的 16 個位元組的文字指標 BLOB 的根節點。 文字 / 影像頁面會組織成資料平衡的 Tree，但沒有的每個資料表文字 / 影像頁面只有一個集合。 AllDocStreams，資料表，這表示所有檔案的內容橫跨相同的文字 / 影像頁面集合。 單一的文字 / 影像頁面可保留資料片段，從多個 BLOB，或它可能會保留中繼節點 BLOB 大於 32KB 的大小。

[圖 1] 中的 [SQL Server 的預設 SharePoint BLOB 儲存

我們不會深入太深 SQL Server 內部，不過。 重點是，當讀取非結構化的內容，SQL Server 必須請透過資料列，以取得文字指標，並再透過 BLOB 的根節點和可能有其他的中繼節點，尋找所有的資料片段散佈在任何數目的文字 / 影像頁面的 SQL Server 必須載入記憶體中取得所有資料區塊的完整。 這是因為 SQL Server 會執行在頁面層級的 I / O 作業。 這些複雜性會影響到檔案的串流處理效能的比較透過檔案系統的直接存取。 SQL Server 也會 2GB SharePoint 上的硬碟的大小限制，因為這是影像的資料型別的最大容量。 在內容的資料行，AllDocStreams 資料表的會是影像資料行，所以您無法在 SharePoint 內容資料庫中儲存大於 2GB 的檔案。

外部的二進位碼存放

ISPExternalBinaryProvider API 提供的是在 SharePoint 內容資料庫內部的 BLOB 儲存區的聰明替代方法。 它是簡單的 COM 介面，只有兩個方法 (StoreBinary 和 RetrieveBinary) 可讓您用來實作的外部的二進位儲存 (EBS) 提供者。 如架構的詳細資訊請參閱主題 (英文) ＞ 外部的 BLOB 儲存的架構WSS 3.0 SDK 」 中

SharePoint 載入 EBS 提供者當您將本機 SPFarm 物件 (SPFarm.local.ExternalBinaryStoreClassId) 的 ExternalBinaryStoreClassId 屬性的設定提供者的 COM 類別識別項 (CLSID)。 每當您送出 BLOB 資料，例如，當您在上檔案載到文件庫時，SharePoint 會再呼叫提供者的 StoreBinary 的方法。 EBS 提供者可以決定 BLOB 儲存其相關聯的外部儲存系統，並傳回對應 BLOB 識別碼 (ID BLOB) 至 SharePoint，]，或它可以在 StoreBinary 方法為 False，表示它並未處理 BLOB 中的設定 pfAccepted 參數。 在後者的情況下 SharePoint 會如往常般儲存內容資料庫中的 BLOB。 另一方面，如果 EBS 提供者會接受 BLOB，SharePoint 只插入 BLOB 識別碼至 AllDocStreams，資料表的內容的資料行如 [圖 2 ] 所示。 BLOB ID 可以是可讓外部的儲存系統檔案名稱、 檔案路徑、 全域唯一識別項 (GUID) 或內容的摘要中尋找的內容 EBS 提供者的任何值。 在範例提供者包含在小幫手] 的內容，例如，會使用檔案名稱為 GUID BLOB 的檔案伺服器上的穩定識別。

[圖 2] 會 儲存在外部儲存體系統 SharePoint BLOB

SharePoint 也會持續追蹤的外部儲存的檔案將這些檔案的最高 DocFlags 位元設定為 1。 DocFlags 會是 AllDocs 資料表的資料行。 當使用者如果要下載的外部儲存的檔案要求時，SharePoint 就會檢查 DocFlags，並將內容的值，從 AllDocStreams 資料表傳遞至 EBS 提供者的 [RetrieveBinary) 方法。 RetrieveBinary 呼叫回應，EBS 提供者必須從外部儲存體系統擷取指定的 BLOB，並返回 SharePoint 在形式的實作 ILockBytes 介面之 COM 物件上的二進位內容。 請注意 SharePoint 會不的 BLOB 儲存在內容資料庫的直接呼叫 RetrieveBinary 方法。

也請注意儲存和擷取處理序是在使用者可以看見，只要，使用者不會嘗試略過 SharePoint。 所以，您不需要取代內建的 Web 組件，與自訂的版本，平局清單與文件中的中繼資料儲存在外部，生產力應用程式，例如 Microsoft Office，不需要知道如何將存入一個位置，然後在另一個，文件的中繼資料和搜尋不需要處理中繼資料與文件分開。 此外，而這是我 EBS 提供者架構的我的最愛的優點之一，使用者必須通過存取外部儲存的 BLOB 資料的 SharePoint。 使用者略過 SharePoint，並直接存取內容資料庫，透過 SQL Server 連線結束下載 BLOB 的識別碼，而非實際的檔案內容如 [圖 3 ] 所示。 您可以確認這個問題，如果您是在測試環境中部署 SQL 下載網頁組件 (我使用 4 月 2009 資料行中，示範如何略過 SharePoint AD RMS 保護)。 使用者不需要另外，— 且不應具有 — 存取外部的 BLOB 儲存區的權限。 因為 SharePoint 呼叫 EBS 的提供者方法，站台的應用程式集區帳戶的安全性內容中，只有 SharePoint 安全性帳戶需要存取。

[圖 3 ： EBS 提供者可以 roadblock，以略過 SharePoint 檔案下載使用權限

請記住，但是，EBS 提供者也有缺點，因為的 SharePoint 伺服器隻 C 的內容資料庫中的中繼資料] 和 [外部的 BLOB 儲存庫之間的完整性的維護複雜性。 如好討論的利與弊，請主題 」 操作的限制和 Trade-Off 分析WSS 3.0 SDK 」 中 請確定您在 SharePoint 環境中實作的 EBS 提供者之前閱讀這個非常重要的主題。

建立一個 Unmanaged 的 EBS 提供者

現在讓我們來處理建置 EBS 提供者的挑戰。 ISPExternalBinaryProvider 的介面是在 WSS 3.0 SDK 中 well-documented 」 BLOB 存取介面： ISPExternalBinaryProvider." 不過，似乎 Microsoft 忘了涵蓋 EBS 提供者詳細資料。 畢竟，我們不只是使用現有的 COM 伺服器的介面。 我們會把自己建立的 COM 伺服器與實作 ISPExternalBinaryProvider 介面。 最重要的是 WSS 3.0 SDK 無法說我們應該，建置並執行緒模型所需的 COM 伺服器的型別。 跨處理序 (Out-Of-Process] 或 [中-處理程序，可以執行傳統的 COM 伺服器，而且它在單一執行緒 Apartment (STA) 模型、 多執行緒的 Apartment (MTA) 模型，或兩者)，可以支援或無限制執行緒模型。 EBS 提供者正常，請確定您建立安全執行緒 (Thread-Safe 同處理序 (In-Process COM 伺服器支援 「 兩者 」 STA 的 MTA 執行緒模型。

您也需要考慮要使用的程式設計語言。 這是很重要的因為 ISPExternalBinaryProvider 介面是 SharePoint 最低層級的 API。 效能問題可能會影響整個的 SharePoint 伺服陣列。 基於此理由我建議使用可讓您建置小型和快速 Visual C ++] 和 [Active Template Library (ATL) 等的 COM 物件的語言。 ATL 會提供有用的 C ++ 類別，以簡化在 Unmanaged 程式碼中安全執行緒的 COM 伺服器的開發使用正確的執行緒支援層級。

Visual Studio 也會包含各種不同的 ATL 精靈。 只要建立 ATL 專案，複製從 WSS 3.0 SDK 介面定義至您的 ATL 專案的介面定義語言 (IDL) 檔案，將新類別加入 ATL 簡單物件的選取的 ISPExternalBinaryProvider 」 同時執行緒模型和沒有彙總，然後新?§，指向 [新增]，按一下實作介面，並選取 ISPExternalBinaryProvider 之伺服器型別中選取動態連結程式庫 (DLL) 中。 就是這樣 ！ 實作介面精靈會執行所有必要的配管，因此您可以專心 StoreBinary 和 RetrieveBinary 方法的實作。

並沒有讓 intimidate 您的 Unmanaged C ++ 程式碼。 如果您分析 SampleStore.cpp 檔案中的小幫手] 內容時，您就可以看到 StoreBinary 和 RetrieveBinary 實作是相當簡單。 基本上是，方法建構檔案路徑，以在 StorePath 登錄值為基礎的 StoreBinary 範例站台識別碼傳入，從 SharePoint 和 GUID，產生的的 BLOB，然後使用 Win32 WriteFile 函式儲存從 ILockBytes 執行個體取得二進位資料。 方法範例 RetrieveBinary，從另一方面來說，會根據相同的 StorePath 登錄值、 站台識別碼和傳入，從 SharePoint，BLOB 識別碼的檔案路徑的建構，，然後擷取非結構化的資料 EBS 提供者會複製到新的 ILockBytes 執行個體再傳遞回至 SharePoint 使用 Win32 ReadFile 函式。 [圖 4 ] 說明 EBS 提供者如何建構檔案路徑。

[圖 4] 的 StoreBinary] 和 [RetrieveBinary 作業，在 EBS 提供者範例的建構檔案路徑

建立受管理的 EBS 提供者

不用說 SharePoint 的開發人員可能會偏好使用熟悉的 Managed 的語言，來建置 EBS 提供者，即使建置 Managed EBS 提供者並不一定比建置 COM 互通性 (Interoperability) 的複雜性因為 Unmanaged 提供者較不複雜。 請注意在 Unmanaged 程式碼中撰寫的應用程式可以只載入一個，Common Language Runtime (CLR) 版本，因此您的程式碼必須使用相同版本的 CLR 所使用的 SharePoint 的其餘部分，否則您可能得到非預期的行為。 而且，您仍必須處理 Unmanaged 的介面和封送，對應處理參數的緩衝區。 小幫手] 內容中，只比較與 SampleStore.cs SampleStore.cpp。 沒有使用 Managed 程式碼結構方面的語言，或程式設計簡單的提升。

此外，留意的 64 位元的相容性問題如果您在開發 Managed 的 x64 平台 EBS 提供者。 [圖 5 ] 顯示一般的錯誤，從開發電腦上 COM 登錄設定不正確產生。 如果您啟用註冊 COM Interop 核取方塊在 Visual Studio 2005 或 Visual Studio 2008 中專案內容中，您會得到您的提供者在 HKEY_CLASSES_ROOT\Wow6432Node\CLSID\ 登錄中的 COM 登錄設定 <providerclsid>。 Visual Studio 會使用組件註冊工具 (Regasm.exe) 的 32 位元版本，即使在 x 64 平台。

[圖 5 導致為無效的 COM 登錄設定中，EBS Managed 提供者無法載入

但是，在 64 位元版本的 SharePoint，無法載入 32 位元的 COM 伺服器下的 Wow6432Node 登錄，使您必須以手動方式登錄 Managed 的 EBS 提供者使用 64 位元 Regasm.exe 版本位於 %WINDIR%\Microsoft.NET\Framework64\v2.0.50727 目錄中。 例如，命令"%"WINDIR%\Microsoft.NET\Framework64\v2.0.50727\Regasm.exe ManagedProvider.dll 建立 HKEY_CLASSES_ROOT\CLSID\ <providerclsid> 下受管理的範例提供者，所需的登錄設定。 另一種方法是建立安裝程式，並標示 EBS 自動的 COM 註冊提供者。

另外也請記得 Managed 的 EBS 提供者隨附還要多的額外負荷和效能處分，比 Unmanaged ATL 對應。 如果您比較登錄中的 COM 登錄設定，您可以看到這。 為 [InProcServer32 金鑰揭露 COM Runtime 會載入 Unmanaged 的 EBS 提供者 DLL 直接，Managed 的 EBS 提供者，並依賴 mscoree.dll 與同處理序伺服器，是 CLR 的核心引擎時。 所以，受管理的提供者，COM Runtime 載入 CLR 然後並 CLR 載入 EBS 提供者組件，組件的機碼下的登錄建立 COM 可呼叫包裝函式 (CCW) Proxy，以處理在 Unmanaged 的 SharePoint 用戶端 (Owssvr.dll) 和 Managed 的 EBS 提供者之間的互動。

請記住，Unmanaged 的 SharePoint 伺服器不會直接互動，與您的 Managed 提供者。 這是封送處理參數、 呼叫 Managed 的方法，並處理 HRESULT 的 CCW。 這個間接取值是不同的 Unmanaged 方法以比較的 Managed 方法的傳回類型尤其明顯。 Unmanaged 的方法會傳回，而 Managed 的方法應該要有 void 的傳回型別，表示成功] 或 [失敗的 HRESULT。 因此不會在 Managed 程式碼中傳回明確的 HRESULT。 您必須提高系統或使用者定義例外狀況，以回應錯誤狀況。 如果 Managed 的方法會完成例外狀況沒有，CCW 會自動傳回 S_OK 給 Unmanaged 用戶端。

另一方面，如果 Managed 的方法會引發例外狀況，CCW 對應錯誤碼和訊息到 HRESULT 和錯誤資訊。 CCW 實作為此等 ISupportErrorInfo IErrorInfo，不同的錯誤處理介面，但 SharePoint 不不是要花利用這些介面。 EBS 提供者必須實作自己的錯誤報告透過 Windows 事件記錄檔、 SharePoint 診斷記錄、 追蹤的檔案或其他方法。 SharePoint 只預期，HRESULT S_OK 成功和值 E_FAIL 錯誤。 您可以使用 Marshal.ThrowExceptionForHR 方法返回 E_FAIL 至 SharePoint，SampleStore.cs] 所示。

在 SharePoint 中註冊的 EBS 提供者

輕鬆地 ISPExternalBinaryProvider WSS 3.0 SDK 中最令人混淆 ＞ 一節 」 主題 安裝和設定您的提供者 BLOB." 在撰寫本文之時這個區段已填入令人誤解的資訊和錯誤。 即使 Windows PowerShell 命令不正確。 當您收到錯誤，表示該 $ providerConfig 不存在時如果指派 $ yourProviderConfig EBS 提供者，並之後使用 $ providerConfig.ProviderCLSID 不要是很驚訝。 連線的不用說您不會甚至到這一點，因為現用和 ProviderCLSID 屬性不是 ISPExternalBinaryProvider 介面的一部分。 這些神秘的屬性屬於未包含在文件中的雙重介面。 純粹為了趣味，我在 Unmanaged 和 Managed 程式碼中實作 [範例版本，但您 ISPExternalBinaryProvider 實作不完全需要這些專屬的屬性。

ProviderCLSID 屬性可能是方便，但 CLSID 也可在登錄中如果您搜尋 ProgID 例如 UnmanagedProvider.SampleStore 或 ManagedProvider.SampleStore，而且您也可以在程式碼檔案 SampleStore.rgs 和 SampleStore.cs 中找到 CLSID。 如前所述，本機 SPFarm 物件的 ExternalBinaryStoreClassId 屬性設定為 CLSID 註冊的 EBS 提供者。 在 EBS 提供者] 登錄移除本機 SPFarm 物件的 ExternalBinaryStoreClassId 屬性設定為一個空的 GUID (「 00000000-0000-0000-0000-000000000000 」)。 別忘了呼叫 SPFarm 物件的組態資料庫儲存變更，並重新啟動 Internet Information Services (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 方法，以及不正確的工作分派到 FileInfo 陣列，directory.GetFiles 結果的另一個神秘的公用程式類別的參考，但我們不太要求在 WSS 3.0 文件的品質。 DirFromSiteId 和 FileFromBlobid Helper 方法會顯示其目的，透過其名稱不正確的 FileInfo 陣列會輕易地取代字串的陣列，或您可以在一個呼叫 DirectoryInfo 物件的 GetFiles 方法以取代 directory.GetFiles 方法。 小幫手]) 資料的記憶體回收行程範例程式會使用 DirectoryInfo 方法，並遵循建議的記憶體回收的步驟順序。

重要的差的 SDK) 說明在記憶體回收行程的範例會與時間條件的處理。 這會是一個重要的問題，因為時間條件可能會導致 misidentification 及刪除在記憶體回收期間有效的檔案。 請看一下 [圖 6 ，說明 WSS 3.0 SDK–recommended) 方法，判斷被遺棄的檔案，藉由列舉 EBS 存放區中所有的 BLOB 檔案，並再從透過站台的 ExternalBinaryIds 集合，表示內容資料庫中，仍然是 BLOB 清單中移除 [所有參考。 BLOB 清單中的剩餘參考應該要指出應該刪除孤立的檔案。

[圖 6 Misidentification 的孤立，因為到時間條件為有效 BLOB

不過，EBS 提供者必須的不用說先完成之前，它就可以將 BLOB 的識別碼傳回至 SharePoint，寫入 BLOB 資料。 根據網路頻寬和其他條件，就可以波動 I / O 效能。 所以，沒有 EBS 提供者無法建立新的 BLOB 有機會 — 的然後會出現在您的 BLOB 清單 — 但完成寫入 BLOB 資料，因此 BLOB 識別碼不還存在於這個集合，您已經決定，ExternalBinaryIds 之後。 因此，參考至新的 BLOB 會保留在被遺棄的 BLOB 清單如果並此時清除被遺棄的 BLOB 您不小心刪除有效的內容項目遺失資料 ！ 為了避免這個問題，範例記憶體回收行程會檢查檔案的建立時間，並將這些項目加入 BLOB 清單超過一個小時舊的。

結論

藉由整合的外部儲存解決方案，與 SharePoint，您可以增加 My.Application.UICulture 儲存效率、 系統的效能和 SharePoint 的伺服器隻 C 的延展性。 另一個優點是這會強制使用者透過 SharePoint 才能存取非結構化的內容)。 提取資料透過直接的 SQL Server 連線內容資料庫時，只會產生二進位 BLOB 識別碼，而非實際的檔案。 不過，EBS 提供者也有缺點，因為的 SharePoint 伺服器隻 C 的內容資料庫中的中繼資料] 和 [外部的 BLOB 儲存庫之間的完整性的維護複雜性。

為了要整合的外部儲存解決方案的 SharePoint，您必須建立 COM 伺服器與它的 StoreBinary] 和 [RetrieveBinary 的方法會實作 ISPExternalBinaryProvider 介面的 EBS 提供者。 您可以建立 Unmanaged 和 Managed EBS 提供者，但請注意的效能和相容性問題如果您要使用 Managed 程式碼。 也請注意 ISPExternalBinaryProvider 介面不包含 DeleteBinary 方法。 您必須明確地移除 「 被遺棄的 BLOB，透過延遲的記憶體回收集合，並小心避免發生時間的情況會導致意外刪除的 BLOB 的有效項目的。

Pav Cherny 是 IT 專業人員和作者，專精於 Microsoft 技術，協同作業的整合的通訊)。 他的出版物包含著重於 IT 作業] 及 [系統管理白皮書、 產品的手冊和書籍。 Pav 會是總裁的 Biblioso Corporation，公司的專長於 Managed 文件和當地語系化的服務。