Architecture overview

Last updated Monday, December 5, 2016 in Sitecore Experience Platform for Administrator, Developer
Keywords: Databases, Scaling

The Sitecore Experience Database (xDB) collects all your customer interactions from all channel sources in a real-time, big data repository. It connects interaction data to create a comprehensive, unified view of each individual customer, and makes the data available to marketers to manage the customer experience in real time.

The xDB architecture is flexible allowing you to deploy single-server, low-traffic solutions as well as highly scalable, high-traffic, multi-server, solutions.

Key components

The key architecture components in the xDB are:

  • Content delivery server (including personalization)
  • Content management server
  • Content databases (SQL Server)
  • Session state server
  • Collection database (MongoDB)
  • Processing server
  • Reporting database
  • Reporting service

Content delivery server and personalization

You can implement content delivery and personalization using a Sitecore application server that serves incoming HTTP requests for website content from the Internet.

Content management server

Content management in this document refers to the core functionality of Sitecore such as authoring and editing content, managing content, and configuring your website solution.

CMS databases (SQL Server)

Sitecore CMS uses the following three SQL Server databases:

  • Core – contains all settings, like a large configuration file for the Sitecore user interface. You can use this if you are customizing Sitecore, for example, by adding new applications to the Sitecore desktop.
  • Master – contains all versions of all content. This is where business users author and edit content.
  • Web – contains the latest version of published content that has reached a final workflow state.

Session state server

The session state component is a session state store used by the content delivery and personalization process. This is a standard ASP.NET session state store provider that includes support for the Session_End event. In Sitecore xDB, the default session state provider is inProc ASP.NET but it also comes with providers for Redis, MongoDB, and SQL Server.

Collection database (MongoDB)

The collection database (MongoDB) is the primary storage for all analytics information and the registry of contacts and engagement automation states. It uses MongoDB – a highly scalable document-based NoSQL database solution.

Processing server

The processing and aggregation component extracts information from captured, raw analytics data and transforms it into a form suitable for use in reporting applications. It also performs specific tasks on the collection database that involve mass updates.

You implement processing and aggregation on a Sitecore application server connected to both the collection and reporting databases. A processing server can run independently on a dedicated server, or on the same server together with other Sitecore components. By implementing multiple processing or aggregation servers, it is possible to achieve higher performance on high-traffic solutions.

Reporting database

The reporting database is a SQL Server database that stores aggregated data from the collection database suitable for fast querying and reporting.

Reporting service

The Reporting Service API allows you to execute queries and extract information from the collection and reporting databases. It is a part of the xDB but you can also configure the Reporting Service as an intermediate reporting server which performs processing tasks and offloads endpoint application servers.

Note

The database names collection and reporting are not official Sitecore product names.

The collection database refers to the functionality and purpose of the MongoDB analytics database.

The reporting and reporting.secondary databases correspond to the SQL Server Sitecore_Analytics and the Sitecore_Analytics_Secondary databases. These are legacy names that continue to be used.

Diagram showing a simplified version of the xDB architecture

xDB basic architecture

xDB data flow

When a contact interacts with your website, the xDB collects all contact and the interaction data. This data flows through the xDB in the following sequence:

  1. A contact decides to interact with a website.
  2. Depending on the geographic location of the contact, the xDB redirects their visit to the closest cluster (data center) through DNS configuration.
  3. Load-balancing software directs the contact to an appropriate Sitecore content delivery server. Contacts stay connected to the same cluster even if they switch devices or use another browser. Contacts can only move to another cluster if all their active sessions expire and all their information is then saved to the collection database.
  4. During the session, details of the contact, the interaction, and the device are stored in either a private or shared session state. On session end, Sitecore flushes this data to the collection database and schedules it for processing.
  5. The processing layer reduces and groups interaction (online visit) data and stores it in the reporting database for use by the reporting layer. This is known as aggregation. Data is also aggregated by the processing layer for use by the segmentation index.
  6. The Reporting Service queries the reporting database to fetch reporting data for use in applications such as Experience Analytics (xAnalytics).
Send feedback about the documentation to docsite@sitecore.net.