Developing Remote BLOB Store Providers

SQL Server 2008 R2

A remote BLOB store (RBS) Provider enables a particular type of BLOB store, known as target BLOB stores, to hold RBS BLOB data. Typically, these target BLOB stores offer larger amounts of storage space at a lower cost than normal SQL Server databases, run on less expensive hardware, and are easier to maintain and expand. This topic describes the technical requirements for RBS providers and provides recommendations and best practices information.

An RBS provider is required to:

  • Provide an implementation of the BlobStore abstract class that uses the target BLOB store to store BLOB data.

  • Allow multiple instances of the provider to be used simultaneously from one or more client machines. These providers may point to the same instance of the target BLOB store, or to several different instances and may use the same or different credentials to do so.

It is recommended that an RBS provider should:

  • Allow the RBS interfaces and configuration options to use and reflect the features of the target BLOB store wherever possible. This minimizes the need for custom configuration options to exploit features of the target BLOB store.

  • Allow attaching, detaching, enabling, disabling, configuring, and deploying target BLOB stores and providers without affecting the availability of SQL Server and client computers.

  • Avoid introducing too much overhead. The performance of an RBS provider should be as close to the performance of native access to the target BLOB store as possible.

An RBS provider must guarantee:

  • Link-level consistency. There should be no dangling BLOB references; if the provider gives out a StoreBlobId to represent a newly stored BLOB, the BLOB should be able to be accessed later using the same StoreBlobId, as long as it is not deleted.

  • That the BLOB persists when a Store method call returns. BLOB data and any metadata that the provider associates with it must be persisted by the store before the call to Store the BLOB returns successfully. This means that if the BLOB store fails due to a power outage or other reason, after the successful completion of a Commit() operation, the BLOB is available when the BLOB store comes online.

It is recommended that an RBS provider should guarantee:

  • BLOB data immutability. BLOB data should not be changed after a BLOB is initially stored. This guarantees that the data returned when a BLOB is read will be identical to the data that was given to the provider when the BLOB was stored.