Intelligently Reducing SharePoint Costs through Storage

Intelligently Reducing SharePoint Costs through Storage



Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones


Goals for Large Content in SharePoint 

Optimizing SharePoint storage is, in many cases, led by an effort to get the large content  items out of SharePoint. When we do that, however, we need to do so with an eye toward  retaining all of SharePoint’s features. We don’t want to just shrink the database for the sake  of doing so if at the same time we’re losing access to features like security, workflow, alerts,  indexing, and so on. 

Remove the Data from the Database 

So the primary goal is to remove just the BLOB data from the database. That leaves SQL 

Server with a cleaner, leaner database consisting entirely of data rows. Problems like  empty space and fragmentation can still occur, of course, but they’ll be much less severe,  meaning you’ ll h ave to perform maintenance on the database less frequently. 

Backups will not necessarily be faster, as you’ll still want to back up the BLOB data,  wherever it winds up living. In fact, one risk is that you’ll have to come up with new backup  routines, depending on how you do offload the BLOBs because your offloading technique  won’t necessarily integrate with SQL Server’s native backup scheme. 

Third­Party Backup Tools 

Some third‐party backup tools rely entirely on SQL Server to deliver the data  to back up. If your offloading scheme takes the BLOB data away from SQL 

Server, then SQL Server won’t know about it—and won’t be able to deliver it  to the backup tool. 

Keep the Metadata in the Database 

We don’t want to pull all of the content out of the database, though. The metadata needs to  stay—that’s information like who owns the file, who has permissions to the file, what  keywords are associated with the file, and so forth. SharePoint needs that information to  manage the file itself, and having that structured data in the database is the best way for 

SharePoint to use it. The metadata, as I wrote, doesn’t take up much space, and it’s really  what the database is for. 

Keep the Content Searchable 

We also want to keep the content searchable, meaning SharePoint has to be able to access  the BLOB contents in some fashion. As you’ll see in the upcoming sections, that means  either SharePoint needs to be able to find the file on its own, or SharePoint needs to be able  to transparently access the BLOB data through SQL Server—even if SQL Server isn’t  physically storing the BLOB data. Figure 2.5 shows the three ways this can work: storing  the data in SQL Server itself (the middle path), using a SQL Server‐side BLOB offloading  mechanism (shown on the left), or using some SharePoint‐based BLOB redirection (on the  right). 



Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones




Figure 2.5 Keeping BLOB content searchable. 


As a convention in this chapter, green arrows will represent the flow of  structured data, while blue represents the flow of unstructured BLOB data. A  green/blue arrow will represent either type of data. 

Any of these techniques will ensure that SharePoint still has access to the BLOB data so that 

SharePoint can crawl that data for search purposes. 

Keep the Content Secured 

We also want the content to remain secured using SharePoint’s security system. That  system is complex enough without layering some other security mechanism on top of it, so  the BLOB data needs to be stored in a way that prevents access to it except through 

SharePoint, or in some other way that respects SharePoint’s priority in controlling access  to the file. What we want to avoid is a situation like that shown in Figure 2.6 where the 

BLOB data lives elsewhere, such as on a shared folder, and can be accessed directly— effectively bypassing SharePoint. 



Intelligently Reducing SharePoint Costs through Storage Optimization        Don Jones




Figure 2.6: You don’t want to be able to bypass SharePoint’s security. 

Simply storing BLOB data on a file server is not inherently a bad thing; what matters is how  the data is secured on that file server. You simply want to ensure that the data can’t be  accessed without SharePoint. Or, if it can be accessed without SharePoint, that any such  access can be synchronized back to SharePoint—so that SharePoint remains nominally in  control of that data. 

Keep the Content Versioned, Alerted, Workflowed, Etc. 

Finally, we need to ensure that all of SharePoint’s other features—versioning, alerting,  workflow, and so on—continue to operate on the data that we’ve offloaded. These features  are the main reason for using SharePoint, after all, so if we lose these features, we’ve sort of  made SharePoint useless. If we can’t offload the data and retain these features, we probably  wouldn’t want to offload the data at all. 

Extra Features 

We might want to add features on top of what SharePoint and SQL Server currently offer. 

For example, we might want to direct different categories of BLOB data to different storage  locations—high‐risk data, for example, might live on redundant storage, while low‐risk  data (like the week’s cafeteria menu) might live on less‐expensive storage. Not every  company will want or need that option, but if you do need it, it’s something to keep in mind  as you explore your options. 


Was this manual useful for you? yes no
Thank you for your participation!

* Your assessment is very important for improving the work of artificial intelligence, which forms the content of this project

Download PDF


Table of contents