email article printer friendly

It's All in the Cache
Weigh your options for data caching in the application tier as an effective technique for improving the performance of data-intensive applications.
by Marie-Anne Neimat

March 28, 2007

Relational database management systems (RDBMSs) are the standard data repositories and transaction engines of the business world. They are deployed typically on dedicated servers and I/O subsystems configured for optimum performance of the database management system (DBMS). Applications that access these databases run on different servers and access the databases through their client/server interfaces or indirectly through application servers or other layers of abstraction.

Various caching techniques have been devised to cache data in the application tier, close to applications. Caching is used to avoid repeated network trips from the application tier to the database server and/or to avoid repeated mappings between an application's data model and the database's relational model. This reduction in network traffic diminishes greatly the latency of data access. Reducing frequent requests to the back-end DBMS has the added advantage of improving overall throughput of the DBMS. Reducing traffic between application tier nodes and the back-end database server can also reduce network congestion.

Before we take a look at various application-tier caching techniques on the market and the advantages and disadvantages of each approach, let's look at what an application is trying to accomplish by caching data in the application tier. The main motivation of course is improved application performance; however, there are other considerations as well, including a read-only versus an updatable cache, currency of the cache, distribution of the cache on multiple nodes, data model and query capability, persistence in the application tier, and availability. Let's look at the details of each.

Read-only versus updatable cache. The most fundamental question when assessing the suitability of a caching technology for a given application is whether the application needs to update cached data, or whether the cached data will be limited to read-only access by the application.

Currency of the cache. The content of a cache can get stale over time if cached data is updated in the back-end DBMS but not refreshed in the cache. There are various techniques that are used to maintain cache currency. Some rely on periodic invalidations of the cache, some rely on periodic refreshes, some rely on instantaneous refreshes, and others rely on instantaneous invalidations when the data in the back-end database is updated. For many applications content that is slightly stale is acceptable. However, for other applications, this condition isn't acceptable; hence, the ability of the caching technology to keep the cache current will affect its suitability for a given application.

Distribution of the cache on multiple nodes. Another consideration is whether the application itself is distributed on multiple application-tier nodes. If it is, then you can assume that there will be multiple caches, with one cache residing on each node. An important consideration then is whether the same data items may appear in many nodes, or whether each data item can be in one node only at any point in time. Multiple copies of the same data item complicate cache coherence, especially if the caches are updatable.

Data model and query capability. Considering the query capabilities required from the cache is also important. The application may require the full functionality of SQL to have access to its rich query capability. Or it may be managing Java or C++ objects with a need for some query capability or no query capability. In the latter case, access to objects may be through their object identifiers with no need for search capability.

Persistence in the application tier. Another consideration when evaluating caching technologies is whether there is a need for persistence in the application tier. In other words, is the cache strictly temporary, and can it therefore disappear if the cache node goes down? Related to the need for persistence are the size of the cache and the availability requirements of the cache.

Availability. An important factor when considering different caching technologies is availability. For example, should access to data continue to be available if the back-end DBMS goes down or if access to the network is impaired? What if the back-end DBMS has a high-availability capability? Should the cache be able to failover to a surviving node?

It is clear that many factors influence the appropriateness of a caching technology to a given application.

Caching Techniques
There are several caching techniques that have been developed and are available on the market. Let's take a look at some of them.

Query result caches are managed by special software that typically hides the presence of the cache from the application. Under this scenario, the caching software automatically saves the results of queries that are submitted to the DBMS. A cache hit is recognized and serviced from the cache if a query is an identical match to a previously submitted query, including identical values of parameters.

The advantage of such caching is that it is simple, and it caters to access scenarios where the same query is likely to be submitted repeatedly. To handle the currency of the cache, some of the DBMSs on the market today provide a notification mechanism to alert the application-tier software that certain values in the cache should be invalidated because they were updated on the back-end DBMS. These caches are limited in scope as they cannot handle query processing on the content of the cache. Further, these caches are not updatable, and they are not distributed.