X

TimesTen In-Memory Database
for Extreme Performance

TimesTen and In-Memory Database Cache

Sam Drake
Architect

Several recent posts I’ve written so far are intended to help explain the basics of what the Oracle TimesTen In-Memory Database is. If you’ve been reading along, you know that TimesTen is a very fast relational database that provides standard interfaces like SQL, PL/SQL, JDBC, ODBC and OCI to access data. TimesTen provides this very fast access to data in large part due to its “in-memory” architecture. TimesTen, unlike most databases, stores all data in RAM. (A copy is also maintained on disk.)

Because TimesTen stores data in RAM, the size of a TimesTen
database is limited by the amount of physical RAM on a machine. On modern 64-bit systems this isn’t much of a
limitation! Today (late 2011) systems
can be purchased which have several Terabytes of RAM, and future hardware will
naturally support even more.

But even though I really like TimesTen, I have to admit …
some databases are bigger than that. J Traditional database systems, like Oracle
Database itself, store data primarily on disk. Oracle Database is obviously a fantastic product, and one of the
benefits it brings is the ability to support very large databases easily … ones
larger than could be cost-effectively handled in memory in many cases.

So TimesTen is a fully featured database, and it can be used
on its own to provide data storage for many applications. But in many cases what we really want is the
best of both worlds … the fast memory-centric performance of TimesTen, combined
with the large capacity and familiarity of the Oracle Database. If only you could have both!

Database Caching

Enter the “In-Memory Database Cache”. IMDB Cache is TimesTen … with a few extra
tricks. It lets one or more TimesTen
databases be used “in front” of a back-end Oracle Database to cache “hot”
data.

There are a number of different ways that IMDB Cache can be
used. Just to get across the basic
concept, here’s one particular scenario. Suppose you run a “shopping” website, where customers log on, browse
your catalog of goods, and place orders. All that data is stored in an Oracle
Database. Your application runs in Java
application servers in the mid-tier. Alongside the application server of your choice, you run TimesTen on the
application server. TimesTen is
configured to cache tables from the Oracle Database.

Let’s say user “Scott” logs on to your website. His first click on the site accesses his customer
profile from the local TimeTen database. But Scott hasn’t been to your site for
some time, so his data isn’t present in TimesTen. So under the covers, TimesTen automatically
fetches Scott’s data from the Oracle Database, storing it in TimesTen for
future reference. This initial load
operation can load a number of items from a number of different tables. In this case, we’ll cache Scott’s preferences
(such how he likes his web pages to be formatted) as well as his shopping cart
contents and recent order history.

So once Scott has logged in to the site, everything about
Scott has been loaded into TimesTen. His
subsequent clicks on the site are all handled by TimesTen. Queries are handled by TimesTen exclusively;
when items are changed – for example, if Scott adds an item to his shopping
cart – those changes are made by the application in TimesTen, which
automatically reflects them in Oracle Database as well.

When Scott logs off from the site, the copy of his data
stored in the local TimesTen database can be removed, freeing up RAM to be used
for other active users. And if Scott
simply goes to lunch, when RAM is needed for other users then Scott’s data can
be automatically reclaimed.

In this scenario, the bulk of database workload of your site
is handled in RAM, by the TimesTen database. The TimesTen database automatically interacts with Oracle Database to
cache information for active users of the site. Users to your site see the fastest possible response time, and workload
on your Oracle Database is reduced.

Since TimesTen’s APIs and interfaces are very compatible
with Oracle Database, the best part is that your application can manage data in
a single relational schema, with a single set of tools and APIs (SQL, PL/SQL,
JDBC, etc.). You can re-use code and
schema used to manipulate data in the Oracle Database to implement a high
performance in-memory cache … without needing to invent a new data model or
data access library. The cache is itself
a fully featured relational database … TimesTen.

As I said, there are many different examples of how TimesTen
(er, the IMDB Cache) can be used to work with Oracle Database to provide
scalable and high performance solutions. We’ll discuss this in more detail in future
articles, I’m sure!

Links

Oracle In-Memory Database Cache User’s Guide … Cache Concepts

White Paper: Using
In-Memory Database Cache to Accelerate the Oracle Database
:


Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha