Internal architecture


Overview of the internal architecture of Sitecore and how it processes and queries data.

Sitecore processes queries using the fastest technology possible. This could be either the SQL database, if the data provider supports the requested query, or in the Sitecore data manager. Note that the SQL database provides the best performance, but, unfortunately does not provide support for all queries.

The SQL database supports queries such as "/sitecore/content/home", which resolves an item by path, and "//home", which locates a set of items by name. For example, if you have a large site that uses an SQL database and you are trying to find all the content items named needle, the following API code retrieves this result set:

Item content = Sitecore.Context.Database.GetItem("/sitecore/content"); Item[] needles = content.Axes.SelectItems("//needle");

The SQL Server data provider supports this kind of query, so the query is resolved directly in the database and runs fairly quickly, even though the database contains a large number of content items.

Adding additional search criteria, however, can change how Sitecore performs the search. Using the previous example, if items include a check box field named IsHidden, then to find needles that are not hidden, you use the following code:

Sitecore.Data.Items.Item content = Sitecore.Context.Database.Items["/sitecore/content"]; Sitecore.Data.Items.Item[] needles = content.Axes.SelectItems("//needle[@IsHidden != '1']");

The SQL Server data provider does not support predicates (the portion of the search string enclosed in square brackets: [@IsHidden != '1']). Therefore, Sitecore resolves this query in the data manager using the query API. To do this, all the items in the query scope (all descendants of /sitecore/content in this example) are loaded so that the predicate can be evaluated against each item and the matching items returned. Unfortunately, the performance penalty associated with loading this many items can be quite dramatic for large sets of items. A more optimal approach is to first find all items named needle, then search through the result set in memory to find the items that are not hidden.