Most Sitecore implementations that I’ve worked with are backed by SQL Server for storing the content. If you look at the database model, you will see that it is quite simple. It is designed around the key principles of the CMS itself (items and field values), rather than the data structure of the content.
This data structure is not only very simple, it also doesn’t really need any relationships besides the one between items and field values (for different languages and versions). In fact, everything comes down to just items and some data related to those particular items. A document-oriented database instead of a relational database may be a better fit!
With this in mind, I attempted to create a data provider for Sitecore that works with MongoDB. And after a few months of not working on it at all, I finally finished it in the last few evenings. Since it has not been properly tested and very likely has some major bugs still in it, I ask you to regard this as a VERY experimental implementation.
Nevertheless, I encourage anyone who is interested to play around with the module that I’ve shared on the Sitecore Shared Source website. You can find the MongoDBDataProvider here.
Setting up the module
Here are some easy steps to get started with the MongoDB data provider.
After setting things up, you can also change the database that your website works with (go to the
Measuring the speed
I’ve said it before:
In my opinion, any performance improvement (especially if it has significant drawbacks) must be proven to be worth it!
So I’ve made a page that tests the performance of any DataProvider that you select. It disregards any caching and tests several different operations a bunch of times and returns how long it took to run the operations. This might actually come in handy if you want to check your own custom made DataProvider.
Go to TestDataProvider.aspx and select the SQL Server data provider and the MongoDB data provider if you want to check the performance gain on your machine. My results are as follows:
|Operation||Duration (in milliseconds) – SQL||Duration (in milliseconds) – MongoDB with safe mode ON||Duration (in milliseconds) – MongoDB with safe mode OFF|
|Change some field values||7005||1325||1092|
|Get parent id’s||2075||318||328|
|Get child id’s||901||275||279|
|Get item definitions||2026||351||348|
|Get item versions||2051||693||676|
|Get field values||1986||656||678|
Note that the safe mode in MongoDB makes writing to the database more reliable, and also a little slower (you can find a setting for this in MongoDataProvider.config). Turning the safe mode off might be interesting on content delivery environments, because that’s where the performance really matters and you can always re-publish something if you need to (though it would be very annoying if this would be needed).
Here’s a chart with the results:
This may seem very impressive, but keep in mind that these results do NOT necessarily translate into similar improvements in speed for your entire website. A few things to keep in mind:
Anyway, it’s been great fun trying this different approach to storing Sitecore data and I hope you enjoyed reading about it!