- Content Management
- October 2017
- Sitecore 8.2
Sitecore - being built on .NET technologies - uses SQL Server databases for persistent data storage. There are a number of databases that each play a role in providing Sitecore functionality, including settings, services, and content storage.
Databases can generally be divided by their use: content, analytics, and reporting.
These databases are the heart of content management in Sitecore, so it is important to understand the role of each:
This is the source of truth for all content in Sitecore. Content items, templates, layouts, settings, and media library items are all stored in the master database. All item versions and all language variations are also stored here. By default, content edits are done against the master database.
Published content is stored in the web database. Only the latest version of each item in a final workflow state is published to web. This also includes one version of each language variation.
Sitecore settings, such as interface definitions, application information, and important system configuration is stored in the core database. User data and ASP.NET Membership tables also reside in this database.
Because Sitecore can be deployed in different configurations to support different roles (content management, content delivery, reporting), these databases can also be broken up by their necessary usage.
- Core is used by any and all Sitecore roles, since it has required settings and configuration need to run.
- Master is used on content management roles, typically one or two servers at a time.
- Web can be used by all roles, but primarily for content delivery, where only the latest version of content is needed.
The three content databases will be spread out like this between content management and content delivery servers:
In Sitecore 7 and 8, MongoDB provides storage for analytics data. Analytics data is the backbone of the Sitecore Experience Database (xDB). MongoDB is used mainly for performance and flexibility reasons: browsing data (including goals, campaigns, etc.) is collected in real-time and written to the xDB after every browsing session. With the release of xDB in Sitecore 7.5, it was determined that collecting data on hundreds or thousands of visitors at once worked best with a document database solution.
Sitecore 9 introduced xDB via xConnect, designed for SQL Server first and foremost, and has corresponding databases built with Microsoft's JSON storage patterns.
Sitecore's reporting database aggregates data from xDB into a SQL Server analytics database. This data is reported through the Sitecore Client and other tools. A seperate "processing" server role should be added to a production deployment of Sitecore to handle the aggregation of this data to the reporting database.
In Sitecore 7, this was referred to as the "analytics database," but is now called the "reporting database" in Sitecore 8 and 9 (probably to prevent confusion with the xDB analytics databases).
Bringing It All Together
Here's an overview of all five databases at play:
Again, this diagram is conceptual only and does NOT represent an actual production deployment. A production deployment would typically involve additional databases for data replication and additional servers for load balancing.
Sitecore uses standard SQL Server connection strings to connect to its databases. These connection strings are found in the following file:
<sitecore root directory>\Website\App_Config\ConnectionStrings.config
This file contains both SQL Server and MongoDB connection strings (for analytics databases).