There is a lot of interest in the ability of SharePoint 2010 to use the new Remote Blob Storage (RBS) capabilities of SQL 2008 R2. Much of it good... some of it bad. The main issue is that many people are under some false assumptions about what RBS does and what it's actual benefits/trade-offs might be.
First, RBS provides a few clear and potentially valuable direct benefits:
That's it. That's what RBS gets you. When discussing a system like SharePoint, which has a heavy focus on file (BLOB) management, these can be fairly significant benefits.
However, these benefits come at a significant price. Specifically:
So, should you use RBS? Maybe, maybe not. If you're clear about the problem you're trying to solve and you clearly understand how RBS fits into solving that problem, then RBS may be a good solution. For example, if all of the following items are true, then you might consider RBS:
If ANY of the above items are not true... ANY OF THEM... then you should NOT be considering RBS.
Now... the true/false, fact/myth part of the conversation...
Finally, if you're still considering RBS or just want more information about it, a recently released whitepaper provides the most exhaustive and informative description of RBS I've seen to date. I strongly suggest reading it.
Note: This article has been updated to reflect the latest guidance from the SharePoint Product Group. Some artifacts may remain that reflect information prior to this update. If so, please leave a note in the comments for invesgitation and response.
Another great post Chris, a keeper! Really clears up some misconceptions and shows you where RBS can be used and more importantly when not to use it.
Great post, I referenced this in my recent blog on the SP2010 SP1 sizing changes:
Thanks for the comments guys, and for the reference Ben. :)
Great post. Definitely makes the topic of RBS clear and clears up misconceptions on who should be using! Thanks!!
Great post Chris, thanks for the info.
On a slightly unrelated note, in the last "fact/myth" response, you mention that a Records Center "should only be used once per farm". Could you expand on why this is the recommendation for the Records Center?
Hi Jason - Great question.
The recommendation is primarily targeted at 2007, but continues to have benefit in 2010 as well. The technical reason is that SharePoint (both versions) offer a "Declare as record" function which will send a given document to the Record Center configured in Central Administration. As this is in Central Administration, and is only a single entry, this means that there should really only be one Records Center in the farm. See technet.microsoft.com/.../cc824902(office.12).aspx for more information on 2007. Also, regarding 2007 we have a note in the downloadable book "Records Management for Office SharePoint Server 2007" (go.microsoft.com/fwlink) which states:
"A Office SharePoint Server 2007 farm can point to a single target Records Center site as the location to which to send records from sites in that farm. If a farm hosting active documents must point to multiple Records Center sites, you must use the Windows SharePoint Services 3.0 object model to implement a custom router in the target Records Center site to route incoming records to the appropriate destination Records Center site. "
In 2010, there should still only be a single default Records Center, but you can configure the routing rules of that records center to route a document to other sites, including other Records Centers. In this case, there can be more than one, but there should only be one "default" per farm. Of course, there is also the option of "in-place" records - but that's a different show. ;)
From a business process perspective, the goal of the Records Center is to provide a single location for records to be managed and a single primary point of investigation. Having numerous Records Centers effectively eliminates this benefit since someone must still fish through a lot of different document repositories in order to do e-discovery.
Creating multiple Records Centers is technically possible, but more than one is of diminished usefullness from both a technology and business process perspective.
Thank you so much for this. This dovetails well with the capacity planning guide where it discusses the 200GB limit.
I was very curious about RBS, and you've confirmed that it's not just a simple thing to plug and chug.