Editor's note: Contributor Trevor Hellebuyck is co-CTO at Metalogix. Follow him @thellebuyck
There is little doubt the SharePoint community is excited for SharePoint 2013. With 60% of users in a recent SharePoint survey saying they want to upgrade in the next year, the anticipation is building to a climax.
One feature that has garnered a lot of buzz, and some confusion, is the new Shredded Storage feature and what impact it will have on binary large objects (BLOBs) storage. In this two-part series, we’ll delve deeper into Shredded Storage, explore its impact on SharePoint 2013 and address the myths about the new feature and Remote BLOB Storage.
Before we plunge into the details it makes sense to define what Shredded Storage is and is not. The term "shredding" has created a lot of confusion. Shredded Storage does not refer to file shredding, which is the secure deletion of files by overwriting the data multiple times. StoragePoint and many other storage-related products include this feature. Instead, SharePoint 2013’s Shredded Storage is an attempt by Microsoft to reduce the I/O impact when saving versions of a document or file by "shredding" it into smaller pieces.
Microsoft developed shredded storage to address an issue that resulted from how document edits or versions are stored in SharePoint and to reduce the number of transaction logs. The result – significantly improved I/O (network and disk) and reduced CPU overhead when storing incremental changes to documents. The SharePoint product team has done a fantastic job addressing what has been a long-standing complaint in the way files are stored in previous versions of SharePoint.
Unfortunately, by addressing one issue, Microsoft introduced another that results in a performance decrease for the uploading and downloading of files in SharePoint.
A Brief History Lesson
With the introduction of SharePoint Team Services and subsequently SharePoint Portal Server 2003, Microsoft moved away from using the Web Storage System and settled on using SQL Server exclusively for the storage of BLOBs. BLOBs are immutable objects when stored in SharePoint. This means that BLOBs are created and deleted but never updated. When editing existing documents in SharePoint, edits result in new BLOBs being created. These new BLOBs are full copies including the edits and not incremental changes.
This means that if you maintain 10 versions of a 1MB document you would end up with approximately 10MB in total storage requirement excluding metadata. While this wasn't the most efficient use of storage it was the simplest way to handle versions without introducing complexity. Unfortunately SharePoint has a tendency to spin off new versions of documents even if only metadata has changed. With the introduction of SharePoint and Office 2010 Microsoft optimized communication between the Office client and the SharePoint server by implementing a file synchronization protocol named Cobalt.
What Does Cobalt Mean?
I am not going to cover Cobalt in nauseating detail as the topic has been covered quite well by Bill Baer in his post about Shredded Storage. What you should know is that Cobalt allowed the Office client to send incremental changes rather than the entire file to the server when a document was saved. The incremental changes were then reassembled on the server and saved as a complete file. Shredded Storage in SharePoint 2013 extends the saving of incremental changes to the database where only file changes are stored rather than entire copies of the file.
The goal of Cobalt and subsequently Shredded Storage is to reduce the network bandwidth utilization (client changes sent to the SharePoint server) and the I/O operations (SharePoint Server sends file to database) that result from incremental changes to documents. In fact Shredded Storage significantly improves I/O operations while reducing CPU overhead when saving incremental changes to documents. What isn't immediately apparent is the negative impact to I/O operations for the inserting of new files and downloading of existing files.
The Test Results
Our test results (see full table here) compared SharePoint 2010 and SharePoint 2013 upload and download times on the same document set. Our lab testing confirms that SharePoint 2013 uploads and downloads are slower — and in some cases significantly slower — than SharePoint 2010. This is a direct result of Shredded Storage. The overhead involved in determining how to split a document into smaller pieces and store those smaller pieces definitely has an impact on the performance for uploads and downloads.
One Size Does Not Fit All
The test results led us to examine the configuration options for Shredded Storage to determine if we could mitigate the negative impact on uploads and downloads. Unfortunately your options are limited. Contrary to other blog posts on the topic, Shredded Storage cannot be disabled. You actually had the option to disable shredding in the SharePoint 2013 beta but that option was eliminated in the RTM build. The only remaining option is changing the default shred or "chunk" size that files will split into when they are stored.
For me, the decision to disable shredding is a bit nearsighted. Not all organizations use SharePoint for document collaboration where content is being updated/edited in large quantities. I would even argue that while some organizations do have collaboration sites where lots of editing occurs, they almost certainly have other sites where documents are simply uploaded and downloaded without edits or new versions being created.
A common example is document imaging where PDF/TIFF images are stored within SharePoint. Those images never change. Or, how about a document center that contains tens of thousands of published documents that are being read rather than updated? What's more, Shredded Storage provides little value. It is true that even with versioning disabled the I/O between the client, SharePoint Server, and database Server will be optimized. However you will not reduce overall storage requirements.
Unfortunately you are relegated to living with Shredded Storage in hopes that Microsoft will provide, at a minimum the ability to disable the feature. An even better would be an option to control Shredded Storage at the site or site collection level for added flexibility.
Solving one problem by introducing another significant problem is going to make for some unhappy campers who are already struggling to keep up with the explosive growth of their SharePoint content.