This is a new
architectural improvement related to management of data storage (large binary
objects) in SharePoint 2013. In this post I am just giving you an overview of
what this concept is and what is the importance of it ,but I am not going in to deeper details here.
Why Shredding?
In 2010, for
e.g. if we upload a file of 10 MB and if it has 10 versions the total size it
would take 100MB to store in db. Even just for a small change like meta data
change or a simple new line addition to the file content, another 10 Mb will be
taking to store this new version. This will be a very huge performance issue in
large environments where there are millions of records and their versions. But
in shredding , it stores only the changes which were made
to it, instead the entire file.
Nothing to do
anything from our side, by default the shredded storage is enabled.
But if you want to disable or re enable you can do it per web application
basis.
What happens internally?
The shredded
storage does the shred (or chunk) the BLOB in to many smaller shreds or pieces, so the
single blob will be constructed in to many chunks . So now when a file is changed,
these changes(only changes) are added to the storage but the previous version
changes are just associated to this storage as a reference (that means here the
previous changes are not taking the space with this change). While requesting for a particular version it combines all the shreds which are associated with this version and gives the response.
Here I am not
showing any test runs to show how much storage is occupying with 2010 and 2013(with shredding), but to know the storage numericals on this topic, refer
this article from msdn .
Thank you,
No comments:
Post a Comment