UniKL Logo

Lehrgebiet Informationssysteme

FB Informatik

FB Informatik
 
LG IS
AG DBIS
 Staff
 Projects
  XTC
  A3: XML-Databases
  DB Caching
  XML Retrieval
  Model-Driven Development...
  Meta-Akad
  Akleon
  WBT
  SHARX
 Intern
 Impressum
AG HIS
Jobs / Tasks
Courses
Publications
Contact
Misc
Impressum
(C) AG DBIS
 

Database Caching

Andreas Bühmann
2003-12-01

Introduction

Web applications are facing an ever increasing number of users as well as the demand of providing each of them with more and more customized, i.e., dynamically generated contents. This places a high workload on every link of the typical processing chain, that is, on the web servers, the application servers, and the database server. While the former ones can often be replicated, the more or less central backend database hinders scaling of the overall application.

The idea of database caching is to disburden the backend by using a number of frontend or cache database servers (caches). These caches, placed close to the application servers, hold frequently used subsets of the backend database which enable the caches to answer queries without accessing the backend.

Questions

This seemingly simple scenario – caches for other kinds of objects are well-known after all – poses a lot of interesting questions:

Specification

  • How can the cached portions of the backend database be specified?
  • Predicates and their extensions seem to provide a very abstract view on the ‘objects’ being cached. Which kinds of such predicates can be handled (more easily than others) and how? How are their possibly overlapping extensions stored and maintained efficiently?
  • How can approaches such as DBCache or DBProxy be improved, possibly be combined, or be embedded into an overall database caching model?

Query Processing

  • How can we decide which queries or which parts of a query we are able to answer by using the cache contents?
  • How can queries be rewritten such that they can be evaluated in a distributed manner among backend and frontend?

Adaptation

  • How do we choose predicates whose extensions are worth caching?
  • If the cache contents are to be dynamically adapted to changing workloads, which strategy is appropriate? Which underlying principle of locality can be exploited?
  • How do we know that the maintenance of a given predicate extension in the cache is no longer useful? (There is a cost with every cached predicate extension if we require its freshness.)

Updates

  • What about updates occurring in the backend or being initiated by the application through the frontend?
  • Updates to the backend have to be propagated to all frontends. When should this happen? When must this have happened in order to provide reasonable modes of consistency and freshness (to be defined)?
    • Is it possible to specify some time interval δ that limits the age of a database view exposed at the frontend?
    • Is it possible for different ‘freshness spheres’ to exist side by side?
  • Having in mind the goal of disburdening the backend: Can updates be applied within a transaction only to the cache and be propagated to the backend after transaction commit?
    • Which levels of isolation can be achieved, which ones can be tolerated?
    • Similarly, what about transactional semantics in general? Is caching worthwhile or even possible if ACID must strictly be ensured? (What update/read ratio is acceptable before caching does not pay anymore?)

Distribution

  • Is it possible to exchange data directly between multiple frontends in a P2P-like fashion?
  • Might database caching play a role in a forthcoming data grid?

Related ideas

  • Caching for web applications on other levels/with other objects:
    • HTML/XML pages: mostly meaningful for static pages only.
    • Fragments of pages: Divide pages in fragments with different frequencies of update; cache some fragments, generate others, and use templates to assemble them.
    • application objects (e.g., EJBs)
  • Replication
  • Materialized views: Use them for answering queries against base tables. (IBM: Materialized query tables, MQTs)
  • Semantic Caching
  • DBCache at IBM Almaden Research Center, cache tables
  • DBProxy