Monday Dec 12, 2011

TimesTen and In-Memory Database Cache

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:


About

This blog will cover the Oracle TimesTen In-Memory Database and the Oracle Database's In-Memory Database Cache Option ... which is also based on TimesTen. The blog is maintained by Sam Drake. He has worked on the TimesTen product for more than 15 years, and is presently an Architect working in TimesTen development at Oracle.

Search

Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today