Introduction
There seems to be some confusion on whether the Oracle TimesTen In-Memory Database is a cache or a system of record.
I often hear comments like:
◉ TimesTen can only be a cache as it has no persistence
◉ TimesTen is only a cache for Oracle databases
◉ TimesTen should only be used as a cache
This blog looks at the TimesTen fundamentals to answer those questions.
TimesTen Persistence
TimesTen is an in-memory database, so all of the data is in memory all of the time. This means that TimesTen can be optimzed for in-memory performance and as a result it can go really fast. Even though TimesTen is an in-memory database, it still supports ACID transactions and database recovery.
TimesTen enables ACID transactions and database recovery much like an Oracle database does. TimesTen has transaction log files which store the REDO and UNDO records for transactions.
TimesTen also has checkpoint files which are like Oracle database data files as they store database objects like tables, indexes, views, materialized views, sequences and PLSQL packages/procedures/functions.
The combination of transaction log files and checkpoint files means that TimesTen can re-start from both scheduled and un-scheduled database shutdown much like an Oracle database does. This means than things like power failure, machines being turned off and databases processes being killed will not result in data being lost.
TimesTen transaction log files and checkpoint files are just files stored on a POSIX file system [eg ext4 or XFS on Linux]. The latency and bandwidth of the persistent storage will determine the database load time, and if needed the database recovery time.
The consequence of this design is that TimesTen has the same persistence and recovery ability as databases like Oracle, MySQL, PostgreSQL and SQL Server.
TimesTen as a System of Record
As TimesTen suports ACID transactions, data persistence and recovery, the TimesTen In-Memory Database can be used as a system of record. Most TimesTen customers do not like single points of failure, so TimesTen is almost always deployed in some high availability configuration.
TimesTen has two different architectures:
◉ TimesTen Classic is a single instance In-Memory Database
◉ TimesTen Scaleout is a multi-instance, shared nothing, scale-out version of the TimesTen In-Memory Database
TimesTen Classic uses replication to enable high availability. There are many different possible replication configurations, but some form of active-standby or active-active are the most common.
TimesTen Scaleout is a sharded database which has multiple copies of each shard to enable high availability.
The TimesTen In-Memory Database enables low latency SQL applications where microseconds matter for systems such as telecommuniations, financial services and trading systems.
TimesTen can be used a system of record, and about half of the TimesTen's customers use it that way.
TimesTen as a Cache
TimesTen can also be use a read/write, or a read-only cache for other databases.
TimesTen supports very sophisticated native read-write caching for Oracle databases:
- For read caching, Oracle database triggers + log tables with polling are used
- Customers define the polling interval on a per table basis to get the commited inserts, updates and deletes of interest
- Data can dynamically be loaded from the Oracle database if it does not already exist the in the cache tables
- For write caching, the committed inserts, updates and deletes of interest are written to the Oracle database
- Parallel replication allows these writes to occur in parallel while maintaining commit order
- OCI array processing or PLSQL blocks are used to optimize the OracleNet traffic for the writes
For read only caching, TimesTen can also be used as a Oracle GoldenGate target. This does not require triggers on the Oracle database.
This means that given one or more GoldenGate configured source databases, the committed inserts, updates and deletes of interest can be captured, replicated and applied to a TimesTen database, whether it is TimesTen Classic or TimesTen Scaleout.
Source: oracle.com
0 comments:
Post a Comment