A: You have documents stored everywhere, don't you? File servers, network attached storage, storage area networks (SANs) — these are some of the storage devices that maintain the whole document corpus of your organization. But what happens to all of these documents when you make the eventual move to SharePoint? End users will definitely want to use the Enterprise Search capability of SharePoint to find documents, regardless of where they are located in the enterprise. You are also going to move a good portion of documents and records into SharePoint (it is an enterprise content management system after all).
While it is the duty of your IT department to sort out the technical specifics, you should understand the basics of SharePoint capacity planning, especially in terms of storage. This will give you a better idea of what storage is going to cost you. Each of the deployment types (on-premise, hosted, cloud-based) will have different costs associated with how storage is procured and used, so we'd recommend you know what you are in for before deciding on a strategy.
Several SharePoint architectural factors will influence your storage needs and your design, including:
- The amount of content
- Deployed features and service applications
- The number of farms
- Availability needs
- Throughput and latency targets
Since SharePoint is database-driven, the majority of data is probably going to be stored in content databases and databases used by service applications, so database sizing, data architecture, and database server hardware are all very important considerations towards creating an optimal solution.
To help get you started, Microsoft provides the following simplistic formula to estimate the rough size of a content database:
- Calculate the expected number of documents (referred to in the formula as D).
- Estimate the average size of the documents that you will be storing (referred to in the formula as S).
- Estimate the number of list items in the environment (referred to in the formula as L).
- Determine the approximate number of versions (referred to in the formula as V).
The value of 10 KB in the formula is a constant that roughly estimates the amount of metadata required by SharePoint Server 2010; obviously this would be increased if your deployment required significant use of metadata.
Note
Please note that this formula is just a starting point, and by no means comprehensive in terms of your total storage needs. Even with content databases, there are additional factors that affect the size including recycle bins, auditing and auditing data, Office web apps, the Office web apps cache, and so on.
This is perhaps your greatest concern. Data scale represents the volume of data your server farms can store while still meeting latency and throughput goals. The greater the amount of data, the greater the impact on the overall throughput and end user experience. The methods used to transfer data across disks and database servers can also affect latency and throughput.
Some examples of optimizing a farm for data and storage performance include the following:
- Sufficient database server resources
- Proper database distribution across database servers
- Proper database volume distribution (for example using unique Logical Units (LUNs), consisting of unique physical disk spindles in SAN configurations)
- Use of Remote BLOB Storage (RBS) to store Binary Large Objects (BLOBs) data on less expensive storage devices