JBoss.orgCommunity Documentation

Teiid - Scalable Information Integration

Teiid Caching Guide

7.1

Legal Notice

1. Overview
2. Result Set Caching
2.1. Support Summary
2.2. User Interaction
2.3. Cache Configuration
2.4. Cache Administration
2.5. Limitations
3. Code Table Caching
3.1. User Interaction
3.2. Limitations
3.3. Materialized View Alternative
4. Materialized Views
4.1. Support Summary
4.2. User Interaction
4.3. Materialized View Definition
4.4. External Materialization
4.5. Internal Materialization
4.5.1. Loading And Refreshing
4.5.2. Limitations
5. Cache Hint
5.1. ResultSet Cache Query
5.2. Materialized Views
5.2.1. TTL Snapshot Refresh
5.2.2. Updatable
5.3. Limitations

Teiid provides several capabilities for caching data including: materialized views, result set caching, and code table caching.  These techniques can be used to significantly improve performance in many situations.

With the exception of external materialized views, the cached data is accessed through the BufferManager. For better performance the BufferManager setting should be adjusted to the memory constraints of your installation. See the Admin Guide for more on parameter tuning.

Teiid provides the capability to cache the results of specific user queries.  When the exact same user query is submitted to Teiid, the cached results will be returned.  This caching technique can yield significant performance gains if users of the system submit the same queries often.

Result set caching will cache result sets based on an exact match of the incoming SQL string and PreparedStatement parameter values if present. Caching only applies to SELECT, set query, and stored procedure execution statements; it does not apply to SELECT INTO statements, or INSERT, UPDATE, or DELETE statements.

End users or client applications explicitly state whether to use result set caching.  This can be done by setting the JDBC ResultSetCacheMode execution property to true (default false) or by adding a cache hint to the query.   Note that if either of these mechanisms are used, Teiid must also have result set caching enabled (the default is enabled).

To control the preference of individual results to remain in memory or the time to live see the cache hint. If a cache hint is not specified, then the default time to live of the result set caching configuration will be used.

Note

Each query is re-checked for authorization using the current user’s permissions, regardless of whether or not the results have been cached.

Teiid provides a short cut to creating an internal materialized view table via the lookup function.

The lookup function provides a way to get a value out of a table when a key value is provided.  The function automatically caches all the values in the referenced table for the specified key/value pairs.  The cache is created the first time it is used in a particular Teiid process.  Subsequent lookups against the same table using the same key and value columns will use the cached information.

This caching solution is appropriate for integration of "reference data" with transactional or operational data.  Reference data are static data sets – typically small – which are used very frequently in most enterprise applications.  Examples are ISO country codes, state codes, and different types of financial instrument identifiers.

Teiid supports materialized views.  Materialized views are just like other views, but their transformations are pre-computed and stored just like a regular table. When queries are issued against the views through the Teiid Server, the cached results are used.  This saves the cost of accessing all the underlying data sources and re-computing the view transforms each time a query is executed.

Materialized views are appropriate when the underlying data does not change rapidly, or when it is acceptable to retrieve data that is "stale" within some period of time, or when it is preferred for end-user queries to access staged data rather than placing additional query load on operational sources.

External materialized views cache their data in an external database system. External materialized views give the administrator full control over the loading and refresh strategies.

Since the actual physical cache for materialized views is maintained external to the Teiid system, there is no pre-defined policy for clearing and managing the cache.  These policies will be defined and enforced by administrators of the Teiid system.

Internal materialization creates Teiid temporary tables to hold the materialized table. While these tables are not fully durable, they perform well in most circumstances and the data is present at each Teiid instance which removes the single point of failure and network overhead of an external database. Internal materialization also provides more built-in facilities for refreshing and monitoring.

An internal materialized view table is initially in an invalid state (there is no data). The first user query will trigger an implicit loading of the data. All other queries against the materialized view will block until the load completes. In some situations administrators may wish to better control when the cache is loaded with a call to SYS.refreshMatView. The initial load may itself trigger the initial load of dependent materialized views. After the initial load user queries against the materialized view table will only block if it is in an invalid state. The valid state may also be controled through the SYS.refreshMatView procedure.


While the initial load may trigger a transitive loading of dependent materialized views, subsequent refreshes performed with refreshMatView will use dependent materialized view tables if they exist. Only one load may occur at a time. If a load is already in progress when the SYS.refreshMatView procedure is called, it will return -1 immediately rather than preempting the current load.

The cache hint may be used to automatically trigger a full snapshot refresh after a specified time to live.


In advanced use-cases the cache hint may also be used to mark an internal materialized view as updatable. An updatable internal materialized view may use the SYS.refreshMatViewRow procedure to update a single row in the materialized table. To be updatable the materialized view must have a single column primary key. Composite keys are not yet supported by SYS.refreshMatViewRow.


The update query will not use dependent materialized view tables, so care should be taken to ensure that getting a single row from this transformation query performs well. This may require the use of depedent join hints. When the updatable option is not specified, accessing the materialized view table is more efficient because modifications do not need to be considered. Therefore, only specify the updatable option if row based incremental updates are needed. Even when performing row updates, full snapshot refreshes may be needed to ensure consistency.

A cache hint can be used to:

  • Indicate that a user query is eligible for result set caching.

  • Set the result set query cache entry memory preference or time to live.

  • Set the materialized view memory preference, time to live, or updatablity.

/*+ cache[([pref_mem] [ttl:n] [updatable])] */

  • pref_mem - if present indicates that the cached results should prefer to remain in memory. They are not however required to be memory only.

  • ttl:n - if present n indicates the time to live value in milliseconds.

  • updatable - if present indicates that the cached results can be updated.

The cache hint, when used in the context of an internal materialized view transformation query, provides the ability to fine tune the materializated table. The hint is not used for materialization targeted at an external source. See the Materialized View Chapter for more on materialized views.

The pref_mem option also applies to internal materialized views. Internal table index pages already have a memory preference, so the perf_mem option indicates that the data pages should prefer memory as well.