I got an email from Michael Warmington who works over at Microsoft as a developer on SQL Server. Mike had read my EBS vs. RBS postings and had a little something to say in RBS’s defense…It looks like I’ve been misrepresenting RBS’s actual capabilities somewhat. In my defense, I make most of this stuff up so it is not surprising that I might not nail it every time!
With Mike’s permission I have included his email in this posting below bound by the [QUOTE] tags. I have added my interpretation of that that means to you if you are looking at RBS from a SharePoint perspective – my comments in red bound by [AMC].
Notes:
- If you are a techie and interested in SharePoint then you really should be using CodePlex.
- You should read this specific entry on RBS - http://www.codeplex.com/sqlrbs. Bear in mind that it relates to RBS as a standalone technology not specifically to how SharePoint uses RBS.
- If you have comments or questions for Mike then contact Michael Warmington through the discussions tab. (http://www.codeplex.com/sqlrbs/Thread/List.aspx)
- Mike is probably paid on a ‘per externalized object’ basis by Microsoft so he may have a hidden agenda too ;-)
[QUOTE]
I think the largest issue of confusion is between the role of the Provider developer and the Application developer. RBS acts as a layer between the application and the blob store, and RBS happens to use the database as a metadata storage area. The application is the final arbiter of whether the blob is stored in an external store or directly in the database, as it has the metadata and context to make that choice. Once the application requests a blob is stored in RBS then we store the blob and return a blob id for the application to store as it sees fit.
[AMC] Is it not RBS that is all or nothing, it is the way that SharePoint uses RBS that makes it all-or-nothing. The only option exposed in SharePoint is to enable RBS for an entire content database – nothing more granular than that… If you turn it on then from that point in time forward all content destined for that content database instance will by externalized. [/AMC]
From the Provider developer's perspective I agree that there is no choice - once the request is made the determination to store in the external store has already been made by the application. This has however been made at the level where the metadata and context allows a more informed decision.
Currently SharePoint 4.0 as an application has an RBS enabled / disabled switch for each content database, and any existing content stored in that db will still be accessible after the enable / disable swap is made without a content copy.
One area of concern is the first bullet point in the RBS Pros:
[AMC] The following is taken from a previous Blog entry. [/AMC]
RBS is implemented in SQL Server and is application agnostic. That’s to say, if you turn RBS on then all BLOB objects from any SQL Server-based application will be externalized. If that’s what you want to happen then that’s great but if you need to be able to apply business logic to what is externalized and whence it goes then you are severely restricted.
[AMC] So, technically the paragraph above should read…
Because of the way that RBS is implemented in SharePoint, if you turn on RBS for a specific content database then all BLOB objects written to that content database will be externalized. If that’s what you want to happen then that’s great but if you need to be able to apply business logic to what is externalized and whence it goes then you are severely restricted.
…I could then add…
Because of this implementation, it also means that you cannot selectively externalize existing SharePoint content, (i.e. you could not run a job that gets all existing minor versions and externalize them to an archive device.) [/AMC]
This is not really correct in that RBS is very application dependent and sits as a layer above the SQL engine. It's actually easier with RBS to apply business logic to storage locations on the application layer as we have support for multiple simultaneous stores - for instance you can have blobs directed towards the EMC provider for important fast access long term storage and other blobs towards a locally attached store for temporary storage.
[AMC] If you want to use RBS outside of SharePoint then know that you have total control of what gets written to SQL Server vs. being externalized. [/AMC]
Link level consistency means that if there's a blob id stored in the user's table it is guaranteed there will be an accompanying blob in the back end store. This is a big deal as it provides some transactional guarantees between the database and the non-transactional store.
[/QUOTE]
Comments