Database Sizing for the Sitecore Customer Engagement Platform – Part 3
In the opening posts of this series I shared many guidelines for sizing Sitecore CEP data based on intended usage of the capabilities of the system. Two additional factors must be considered. First, your organization’s need for high availability, disaster recovery and backup will easily multiply the overall storage requirements. Finally, the anticipated growth trajectory and life span of your site also must be considered.
Governance plays a critical role in any Sitecore deployment
Learn more about Best Practices for Sitecore
High availability, disaster recovery, and backups
High availability (HA), disaster recovery (DR) and backup practices for Sitecore are well documented on SDN and the Sitecore community and are not covered here. I will just mention briefly that your HA, DR and backup strategies must be accounted for in your total space computations.
Most of our clients use a SQL cluster with shared storage for HA, which means there is no additional storage footprint; however several enterprise customers choose to operate a fully replicated DR environment – again adding another copy of the database – possibly a total of 4 copies if dedicated reporting databases are in place. With our previous example the growth over 6 months would now look more like:
Depending on your backup strategy and retention you will also need to add in considerable capacity. As it is the definitive source, most customers only backup the database that is capturing information. A 4 week retention cycle of a complete weekly backup is probably the most common. Factoring in 4 weeks of retention on the data and ignoring compression the graph now looks like:
Note: the backup size for any month is assumed to be 4x the data foot print for the month. This results in a conservative number if only weekly full-backups are taken, but does not account for incremental backups. Actual backup requirements will depend on the level of compression available in your backup solution.
Planning for success, growth of the DMS database
The final consideration is how much growth you expect. In most enterprises there is almost always some contention for space in the data center. For the sake of example, let’s assume our fictional site has a growth in traffic of 25% annually and the capital expenditure committee needs 5 year projections.
If we are conservative and assume the growth happens at the end of the year we now arrive at an active data footprint of 600,000 MB in year 5. You will also note that the database itself is approximately 70 GB. Is your DBA ready to handle a SQL database of that size?
We hope you have found this series helpful. To summarize, in order to estimate your storage needs for DMS you will need to:
- Understand your projected number of visits, visitors and page views
- Understand your project number of page events (goals, campaigns, etc)
- Model any engagement plan you intend to deploy
- Have clear understanding of high availability and disaster recovery needs
- Have defined backup and retention policies
- Account for some level of growth
Choose the language
Posts by date