Shortcomings of SharePoint RBS (Remote Blob Storage)
First of all, many of you are wondering what RBS is. Remote BLOB Storage (RBS) is an API that is available as an add-on feature pack for Microsoft SQL Server 2008 and Microsoft SQL Server 2008 Express. It is designed to actually move the storage of binary large objects (BLOBs) from costly storage on database servers to cheaper storage solutions and is also available as such for SharePoint Portal Server. The advantages of RBS are that it can save you a significant amount of storage space, conserves hardware resources and allows the end user transparent access to their data.
Normally, as in ‘by default’, SharePoint will store all of its BLOB data in the content databases. As the size of these databases keep increasing the amount of BLOB data actually grows significantly faster than any associated metadata in the databases. This will actually result in SharePoint using up a lot of expensive SQL Storage space. Using RBS to move the data outside of SQL actually resolves the cost problem and you can use RBS to store BLOB data on storage devices that are much cheaper than the storage you are using for SQL. One of the major pros is that it is simple. Once enabled all content is simply stored on the storage repository.
There is however a few cons that you should be aware of. Just removing the BLOB out of the SQL database only solves part of the problems that you might have. It might give you some breathing room on the SQL / SharePoint Server, but won’t help you much with compliance issues. The biggest concern is however that RBS is all or nothing. Once you enable it, you get all the data all the time, regardless of the size or business rules you want to configure. In reality it would make sense if you could have RBS push data out that isn’t used that often, more of a tiered storage idea. That way regular used data wouldn’t be pulled from lesser performance data (either on premise or hosted) and is readily available for the end user.


January 12th, 2010 at 7:41 pm
Tiered storage between the database and external storage may make sense, however tiering of storage most often occurs in the storage system itself. Most high-end document management products (documentum, etc.) don’t support in-line (in the case of documentum) and external storage either.
Now what would make sense is for RBS to support native storage to alternative (non physical) devices via UNCs or URLs such that content could be place in other external products more easily.