TimesTen version 7.0 was just released for TimesTen” home page. The product is available for Linux, Windows, Solaris, HP Tru64, HP-UX, HP-UX Itanium, and IBM AIX.
Oracle TimesTen In-Memory Database is a memory-resident relational database that empowers applications with the instant responsiveness and very high throughput required by today�s real-time enterprises and industries such as telecom, capital markets and defense. Deployed in the application tier as an embedded database, Oracle TimesTen In-Memory Database operates on databases that fit entirely in physical memory using standard SQL interfaces.
The biggest feature of the 7.0 release is easy-to-use caching. What this allows you to do is leverage your middleware tier and reduce latency to customer interaction. Instead of going back to the master database, you can hit the TimesTen cache copy of the master database. The driving trends helpign with adoption of this product is the demand for real-time enterprise analysis. SOA is requiring an increase in data and metadata access. Business intelligence is looking at data flows and metadata descriptors. Many of the batch analytics that were done during the night can be done during the day and not after hours. The key benefits are offloading the database hardware requirements, reducing data latency, and allowing for extension of the middleware analytics.
Some of the new features also includes support for upto a terabyte of memory to host data as well as international language support. All of the languages supported by the Oracle database are now supported by TimesTen. There are hardware vendors that allow for multi terabytes to be configured in memory; Sun, Fujitsu (1T), HP, IBM(2T), and SGI(128T).
The cache component allows for rows, columns, or tables to be pulled into the TimesTen cache and available to the application layer. If data is changed in the backend database, updates are pushed to the cache rather than invalidated. The caches should always contain the latest updates from the master repository. Alternatively, data that is active or soon to be active can be pulled into the cache based on who is logged into the web service. Instead of pulling a whole table into the cache, just the customer relevant data is pre-populated before the customer asks for the data. This mechanism is very good for supporting portals that don’t currently scale, product information, and shipping data based on a customer. A third mechanism that can be used is a sliding window. Users can define a sliding window that defines relevance. Instead of loading a whole table, only data changed since a given fixed date is pulled into the cache. For example, when a customer logs into their bank they typically only want to look at current ballances and transactions since the last statement. The login can pull the last 30 days transactions for this customer and get the in-memory database populated before the customer wants to start looking at the data. The different cache methods can be mixed and matched to support applications at the middle tier.
One thing that is interesting with TimesTen is that it allows for data replication from the master repository similar to what is done with RAC. It functions differently than RAC in that the querries are performed at the middle tier layer and not at the database. This is an alternate way of providing scalability without RAC or on top of RAC.
TimesTen is a relational database cache for data shared via Oracle database. TimesTen allows you to pull this from the master reposiroty. This differs from Coherence which is a distributed data repository that shares data in a peer-to-peer grid. The data is not stored on a disk but is kept as an ad-hoc data grid that stays in memory on all of the nodes.
As part of our library system design, I will look at how we can use TimesTen as an optimizer to speed up user requests. We will also look at locking requirements for the database and how this can be done at the TimesTen layer.