Tamino XML Server Version 9.7
 —  Performance Guide  —

Tuning Schemas and Queries

You can influence the performance of Tamino by adhering to the following general principles:

The success and speed of a query run against the Tamino database depends on the combination of index type defined for an XML object and the type of query that will be run against it. Another factor is the mapping type that determines where the object is stored. If typical requests of the application are known, the index types can then be set to support the most typical queries.

This section examines these factors and indicates the settings that are most likely to bring you optimal performance.


Using Structure Index

The default value "CONDENSED" on the structure-index attribute on the Doctype specifies that instance nodes not explicitly mapped in the schema will be registered in the structure index. This provides index support for wildcard and descendant operators in structural queries for nodes not mapped in the schema and thus improves query performance in those cases, in which there are no resulting documents. If you use for example the query "_XQL=a/b" with a condensed index, the result shows that the path a/b does not exist in the respective doctype. Thus query performance increases. With a condensed index, Tamino's optimizer knows if the index information is complete. Queries with wildcards (*) or the path operator (//) are much faster.

A full description of general attributes is given in Tamino XML Schema Reference Guide.

An enhanced query performance can be achieved with the use of the value "FULL" for the structure index. In this case, the structure index shows which path occurs in which document. The value "FULL" causes all instance nodes not defined in the schema to be registered by their structure and therefore significantly improves the performance of queries for such nodes. Another situation, where the "FULL" structure index is very useful is the case where optional elements in the schema are used in queries and there are only a few document with this optional element in the database. The price for using this setting is a slower load operation and a larger index. Though the default value is recommended for most applications, the value "FULL" has its value in situations in which heterogeneous instances of a doctype are expected with a number of element names that may not be known at schema definition time. As with other mapping aspects that impact performance, it is a trade-off between loading time and index size on the one hand and expected nature of the documents and queries on the other.

The value "No" is also recommended for documents with known elements in a random structure (for example, XHTML).

Top of page

Basic Indexing

Text Index

The text index creates an index for full text search capabilities. This index type is optimal for retrieval of words, as it supports the contains operator (see tf:ContainsText) , as well as the operators "adj" (see tf:ContainsAdjacentText) and "near" (see tf:ContainsNearText). Examples of using this operator are:

_xql=/patient[name/surname~='atkin*']
_xquery=declare namespace tf="http://namespaces.softwareag.com/tamino/TaminoFunction
for $p in input()/patient
where tf:containsText (/$p/name/surname, "atkin*")
return $p

One of the effects of the contains operator is that the request is normalized, basically meaning that the request is not case-sensitive (however, this behavior depends on the settings of the schema element ino:transliteration; for a detailed description see section Representation and Handling of Characters in Unicode and Text Retrieval). The effect of the wildcard character (*) is that all instances of "patient" are found whose surnames contain a word starting with "atkin".

Note that a text index creates an index for the whole content of the node. Node content in this sense means the concatenation of all descendant nodes (but not attribute nodes) that contain text. Setting a text index on intermediate nodes should therefore be practiced with caution.

The impact of a text index on performance is that creating index data takes time, which is an important consideration when loading data. The more data is loaded, the greater the impact on load time. You must therefore use it with a degree of caution rather than liberally.

Text indexing is not possible for data stored into doctypes with the noConversion flag set.

Standard Index

Define all primary and foreign keys used in the conceptual model as index of type standard.

Nodes that are used as sort criteria should be defined as indices of type standard also.

With a standard index, if an element has a string data type of xs:string, a string index is created. For this element, only string comparisons can be handled via the index, making the internal lookup much faster, and numeric comparisons are done without an index lookup. In the case of the "=" operator, the index is used for a preselection. Similarly, if the element has a numeric data type of xs:integer or xs:float, only numeric comparisons can be handled by the index. String comparisons must be done without an index lookup. Thus, if an element born has a numeric index, then born > 1950 will generally be answered much faster than born > "1950" because this element has a numeric index, but no string index.

Standard and Text Index

For performance reasons, it is recommended to use this type of indexing only if it is absolutely necessary, because it means both a text and a standard index is created. This may lead to slower indexing operations.

However, this index type has its uses. An example of this is if you wish to search for patients whose surnames start with "At" (requires text index) but you also want to accelerate sorting the output alphabetically by surname (requires standard index).

Top of page

Result Size

The size of the query result set should be small, because the following rule applies: The larger the size of the result data, the longer the query response time. Especially on large databases, it is easy to construct queries which deliver large amounts of data. That is a very time-consuming process. There are two reasons for the time consumption:

If you are not sure if the size of the result data will block the system, it is recommended to compute the expected size of the query result set. Use the function count(), or a cursor, or formulate queries which will request the ino:id of the XML instances instead of the whole data (e.g.: /my_doctype[ac~="willi"]/@ino:id). In the following query, use the ino:id to retrieve the data.

Alternatively, you can use cursoring to restrict the result set to a subset of the documents that match the query. For more information, see for example the section The cursor command in the X-Machine Programming documentation.

Top of page