Wednesday 25 September 2013

TimesTen - Application Tier In-Memory Database for Performance and High Availability

Adapted from Tirthankar's #OOW13 presentation - thanks!

TimesTen is a separate database with separate binaries.  It shares a lot of functionality with the oracle database, but it's very different.  This is a listing of facts and figures from a presentation on the TimesTen database.  I need to be honest with you, if you're using JD Edwards this is going to be a tough option - ESPECIALLY now that oracle in-memory has been released in 12c.

A special note too, there is no columnar organisation in TimesTen, it's only available in the oracle in-memory option.  Imagine what is going to occur when this is implemented! There is also no compression in the "non exalytics" version of TimesTen.

TimesTen is the in-memory database for the application tier or used as a OEE cache.  
TimesTen is part of the exalytics machine (Adaptive in-memory cache).  Exalytics brings in the data from other systems into a TimesTen database and that is used for analytics.

TimesTen is very light weight, so it's thought that it'll not be replaced by oracle in-memory.

TimesTen is often used with very specialised applications. It's a standard relational database.  TimesTen is only in memory - no caching, the entire database is in memory all of the time.  TimesTen is also persistent.  It logs, checkpoints and can do replication.

TimesTen uses standard config. standard SQL, OCI etc.  TimesTen was launched in 1998, oracle bought it in 2005.  

This is a stand-alone purchase, separate from OEE.

Communications industry uses TimesTen a lot.  TimesTen could cache a subset of data and be called upon from the oracle database.  It's a very specialised database that is used is low latency environments.


I know that this is a JD Edwards blog, I need to determine if TimesTen is supported on the enterprise server, it seems like this would fly!  It's doubtful that you could use TimesTen is a supported environment for JD Edwards, but I think that it would work.

Some stats:
Readers and non-blocking.  read response time, 2.37 micro-seconds.  49 million reads per second.  updates in 7.67 micro-seconds.  This is database SQL operations that return in micro-seconds.  These numbers are based upon real transactions.  TimesTen can perform close to 1000000 updates per second, limited by bandwidth for logging and checkpointing.  An OLTP mix of reads and writes 2500000 operations per second on commodity hardware.

T5-8 can perform 50000000 SQL statements per second (128 cores, 1024 threads).  Mixed workload was 3.5 million operations per second.

You can use EM12C to manage your TimesTen database.

In-Memory Database cache.  It can be kept in sync with the database.  This TimesTen database can complement the oracle database.  

There was a great case study with USPS and the online stamp printing website.  TimesTen was used to check timestamps of postage to ensure that it's not a duplicate of a previous stamp print.  The savings in fraud easily paid for the investment in TimesTen.  They need the speed and the throughput because of the sorting machines that validate the postage need to run so quickly.




No comments: