Operational Limits and Trade-Off Analysis
This content is outdated and is no longer being maintained. It is provided as a courtesy for individuals who are still using these technologies. This page may contain URLs that were valid when originally published, but now link to sites or pages that no longer exist.
The external binary large object (BLOB) store provider, or EBS Provider (ISPExternalBinaryProvider), allows you to store and retrieve unstructured binary streams to and from the external BLOB store. This allows the external BLOB store to work in parallel with your Microsoft SQL Server content database, which contains your application's structured data. However, because the EBS Provider is relatively simple (by design) it imposes operational limitations. Furthermore, installing and enabling the EBS Provider adds complexity to your SharePoint deployment that affects backup and restore operations, garbage collection, and other aspects of your deployment.
Limiting Factors and Trade-Off Issues
Following are some of the key issues to consider when implementing the EBS Provider in your SharePoint deployment:
Data streams in the external BLOB store are never altered or updated; this maintains file-level transactional consistency between the SQL Server content database and the parallel external BLOB store.
When an edited or updated SharePoint file is saved, the EBS Provider does not overwrite the existing BLOB. Instead, the EBS Provider creates a new BLOB stream and places it in the external BLOB store. Metadata references to the original BLOB and its BlobId are deleted from the SQL Server database; then, the EBS Provider creates a new reference (with a new BlobId) to associate the newly created BLOB.
Of course, this scheme results in the accumulation of orphaned BLOBs in the external BLOB store; depending on the rate of updates to BLOB data in your system, the number of orphan BLOBs can easily become quite large. For this reason, you must analyze and quantify your rate of update and implement garbage collection on a schedule that is sufficient to maintain your external BLOB store efficiently. (For more information, see Implementing Lazy Garbage Collection.)
Note
Garbage collection itself is a resource-intensive operation, both for the external BLOB store and for the SQL Server content database, so you must ensure that you schedule garbage collection in a way that does not compete for application resources during periods of peak usage.
The external BLOB storage feature in the present release will not remain syntactically consistent with external BLOB storage technology to be released with the next full-version release of Microsoft Office and Windows SharePoint Services. Such compatibility was not a design goal, so you cannot assume that your implementation using the present version will be compatible with future versions of Microsoft Office or Windows SharePoint Services.
In its current version, external BLOB storage is supported only at the scope of the farm (SPFarm). Furthermore, you must install, configure, and enable the EBS Provider on each front-end Web server in the farm.
Any error conditions, resource drag, or system latency that is introduced by using the EBS Provider, or in the external BLOB store itself, are reflected in the performance of the SharePoint site generally.
No utility is available for moving BLOB data from the content database into the external BLOB store. Therefore, when you install and enable the EBS Provider for the first time, you must manually move existing BLOBs that are currently stored in the content database to your external BLOB store. You can do this in two ways.
You can use site-level backup and restore methods on the SPSiteCollection object to backup and restore your entire data store. After first backing up all of your data, and then installing and enabling the EBS Provider, when you Then when you invoke the restore operation, the EBS Provider routes BLOB streams to the external BLOB store, while routing structured data to the appropriate tables in the content database.
A second, passive method relies on the issue discussed earlier in this section. Because new BLOB data streams are saved to the external BLOB store whenever a file is updated, you can simply install and enable the EBS Provider and then allow the natural process of file updates to gradually populate the external BLOB store with binary files that were previously held in the content database. When an updated file is routed to the external BLOB store, the previous version of the file is automatically deleted from the content database.
When using an external BLOB store with the EBS Provider, you must re-engineer your backup and restore procedures, as well as your provisions for disaster recovery, because some backup and restore functions in Windows SharePoint Services operate on the content database but not on the external BLOB store. You must handle the external BLOB store separately.