There are many application-level caching techniques. For example, in a CICS environment, you could use data tables; in a COBOL batch program, an array; or in a remote Java application, a global cached object. We’ve seen lots of algorithms for hashing key information into objects for quick online retrieval, with the cache broken at certain intervals so it could be refreshed from the database. This allows for a balance between the currency of the data and usefulness of the cache.
Overall, one of your best options for caching is at the application server level.
There’s some potential for caching at the client level, especially if your applications reside in a two-tier environment. This mainly involves caching things such as code values in drop-down boxes for selection on a screen. With most modern user interfaces being Web-based, thin clients, this technique is becoming less useful. However, it still can be useful for simple code values. From a security perspective, application server-level caching is a better balance between protecting the data and performance.
Cache Data Servers
There are several cache data server products on the market today. These are database products that keep 100 percent of the data in memory. The cache data server is typically placed closer to the application than the central database and is intended to speed access to common database objects or entire databases. So they’re most effective in a multi-tier environment and co-located with the application server component. They typically can be seamlessly incorporated into the data access component of an application, and so, unlike any homegrown caching method, there’s no extra programming required. The cache data servers are typically kept in sync with the main databases via replication. So, a replication product either comes bundled with the cache database or must be purchased.
Replication can be one directional or bi-directional, and as with any replication effort there can be issues to deal with such as update latency and collisions. The advantage to the cache data server would be a simplified implementation and automation.
Caching can be an extremely effective way to improve the performance of your enterprise applications, but it doesn’t replace good application and system performance tuning. The concepts of enterprise database architecture and a data services layer have merit, and when performance is critical exceptions should be made and specialized code put in place. In this way, most of your development follows the standard for data access. The applications that require that extra something would get some customization, especially for the high-volume stuff. This approach can work well. You can improve performance of an application by tweaking the process that impacts the application. You can get a performance boost without sacrificing methodology.
While local caching can help offload database server cycles to less expensive platforms, it won’t reduce overall CPU consumption. CPU utilization generally increases with an enterprise data services architecture. Tuning is the best solution and it involves some customization, at least for the high-volume stuff.