TimesTen
Technology
For Epoch Well
March 16, 2006
TimesTen In-Memory
Database
History and
Technology
Background
When You Think “Database…”
Application SQL
RDBMS
Application Results
RDBMS + client/server connectivity
NOT fast enough for a new category of
performance-intensive applications
RDBMS with Home-Grown Cache
Application SQL
RDBMS
Application Results
For very demanding applications:
Build a home-grown, application-specific, in-
memory “cache”.
Combine the cache and the
database into ONE product …
SQL
SQL
Application
RDBMS
SQL
Application
Results
+ Full capabilities of a relational database
+ Memory-optimized speed & latency
+ Optimized for embedded architecture
+ Persistent, recoverable, highly available
History of TimesTen
Early 1990’s “Smallbase” project at HP Labs
Embedded into HP Opencall in 1995
HP Spinoff into TimesTen, Inc. in 1996
First customer revenue and shipments in 1998
Profitable and cash-positive before acquisition
Acquisition by Oracle Corporation in June, 2005
1,500+ Customers Run TimesTen
• 7 of the top 9 NEPs build products with TimesTen
• The world’s most popular telecom BILLING SYSTEMS use TimesTen
• 4 of the top 5 WIRELESS OPERATORS in Europe use TimesTen
• The largest CALL CENTERS in the world run on TimesTen
• Over 40 OEM and ISV solutions are built on TimesTen
In Networks In Telecom On Wall Street In the Enterprise
Real-Time Program Trading of Equities
Lehman Brothers Fixed-Income Trading System
Internal
Trading Desks
TimesTen Usage ( different geography
or class of instrument )
Event capture (trade orders)
Order processing (trade matching) Orders,
Event publishing (trader alerts and closed orders) Inquiries,
Notifications
Performance Metrics Active Active
TimesTen TimesTen TimesTen TimesTen
1,000 fixed-income trades/hr (30/sec peak)
20 trader alerts/sec
Trader Trader
Alerts Alerts
Configuration XLA
Standby
XLA
Standby
4-CPU Server (plus hot-standby) per location Application Application
Closed
Linux with C++ applications Order Data
2 Gigabyte TimesTen Tibco
Messaging
Value of TimesTen Aggregated
Fast order execution Reporting
Trader alerting
Global
Order
Repository
TimesTen In-Memory
Database
Technology
Introduction
TimesTen Technology Basics
High-performance in-memory
database software
Optimized memory layout and
algorithms TimesTen
Flexible options for data
persistence to disk
Applications access the
database via standard APIs
(SQL,ODBC, JDBC) Disk
Persistence/
– Protect, Extend, Evolve your
Recovery
existing investment in RDBMS
How Big a Database Can I Build?
Database must fit into RAM
32-bit operating systems
– 2 GB on most platforms
– 1 GB on Windows and HP One Shared
Memory Segment
64-bit operating systems
– Limit is available RAM
For larger databases, use Disk
Persistence
TimesTen to cache Oracle
data
TimesTen Platforms
Linux on x86, Opteron (64 bit), EM64T (64),
Itanium (64)
Sun Solaris 8, 9, 10 (32 bit & 64 bit)
HP/UX on PA-RISC and Itanium (32&64)
HP Tru64 (64 bit)
IBM AIX 5.3 POWER (32 bit and 64 bit)
Windows 2000, XP, Server 2003 (32 only)
TimesTen
Architecture
TimesTen Architecture
Directly TimesTen
Connected Main
Applications Daemon
Engine TimesTen
TimesTen
TimesTen
Subdaemon
TimesTen
(ODBC Driver) Subdaemon
Subdaemon
Database I/O Subdaemons
Data in
Disk
Shared Memory Persistence
Client/Server Connections to a Data
Store
TimesTen Direct
Connect
Client Server Application
Application
TimesTen Engine
(ODBC Driver)
TimesTen TCP/IP
Client Driver
(ODBC or Data Store in
JDBC Driver)
Shared Memory
MicroLogging™ - Resilience to
Application Failures
TimesTen Daemon monitors application health
If an application aborts, an in-progress
transaction is rolled back
Database remains fully available
Shared Memory is NOT corrupted
Directly TimesTen
Connected Main
Applications Daemon
Architecture Comparison
Why Is TimesTen So Fast?
TimesTen needs fewer CPU instructions to
accomplish the same work as a disk RDBMS
– Physical memory addresses are used
inside the engine
– No lookups of logical addresses to
physical addresses
– No buffer cache management overhead
TimesTen Performance
TimesTen Throughput
12-CPU IBM AIX POWER 1.2 GHz
Sun Solaris 9, 1.6 GHz Sparc, C with ODBC
300,000 Reads
Per Second
100,000 Writes
Per Second
Lightning Fast Response
Average Response Times
TimesTen/DataServer 5.1
Sun Solaris 9, 1.6 GHz Sparc
45
40
35
37µs 36µs
Microseconds
30 Update Insert
a Record a Record
25
20 INSERT UPDATE 15µs
15
Capture or update data
10 Retrieve a
in 40 millionths of a SELECTRecord
5 second
0
Database Operation
ODBC, JDBC, Client/Server
100% Read, 4-CPU Xenon x86 3/0 GHz, Linux
4-CPU 2.8 GHz Linux
300000
271,000
Direct
250000
Client/Server
Transactions Per Second
200000
171,000
150000 Series1
100000
51,000
50000 35,000
0
ODBC Direct C++ C/S
ODBC with ODBC or C JDBC
JDBC Direct JDBC C/S
Data Durability &
Recovery
ACID Properties
Full support for
transactions
(COMMIT/ROLLBACK)
Row-Level Locking
Versioning
Writes do not block
reads
Reads do not block
writes
Durability: Disk Storage
Hard Disk
Applications Non-blocking
Checkpoint Datastore.ds0
Engine Datastore.ds1
(ODBC Driver)
TimesTen Datastore.log1
Subdaemon
TimesTen Datastore.log2
Data Store Logging Datastore.log3
Checkpoints are performed automatically ONLY in TimesTen 6.0 and above
Three Logging Types
Dynamically configurable with SQL statements
LOG
TimesTen BUFFER In-Memory
….. Tx …...
Data Store ……Tx ……
…...Tx……
Logging Hard Disk
Buffered Datastore.ds0
LOG
TimesTen BUFFER Logging Datastore.ds1
….. Tx …...
Data Store ……Tx ……
…...Tx…… Datastore.log1
Datastore.log2
LOG
TimesTen BUFFER Datastore.log3
Data Store COMMIT
COMMIT Durable
COMMIT
Commit
TimesTen Data Store
Recovery
Datastore.ds0
Datastore.ds1
Datastore.log1
TimesTen TimesTen Datastore.log2
Data Store Subdaemon
Datastore.log3
2. Transaction Log
Rollforward
TimesTen Advanced
Features and
Functionality
TimesTen APIs
SQL and Relational at the database core
No proprietary API
JDBC driver provided for Java
ODBC (Open Database Connectivity)
provided for C and other languages
C++ API (“TTClasses”) included with
TimesTen
– TTClasses calls ODBC underneath
Compatible with 3rd party ODBC and
JDBC tools
Memory-Optimized Indexes
Hash Indexes
– Extremely fast exact matches and equi-joins
– Created automatically when a primary key is
specified
T-Tree Indexes
– Memory-optimized index technology
– Use SQL “CREATE INDEX” like other
databases
– Very fast exact matches, range searches
Cost-Based Optimizer
– Explains and Hints
Transaction Log Monitoring and Event
Notification (XLA)
Track changes to tables and
materialized views
Support multiple, concurrent
XLA applications per data store
Maintain log positions via
Bookmarks
Supported with C++ in
TTClasses
New Java/JMS API in
TimesTen 6.0
Example XLA Applications
Trigger-like functionality
– Any INSERT, UPDATE, DELETE in the database can be
monitored
– For UPDATEs, the old and new copy of the data is visible
– 1000s of transactions per second – much faster than triggers
Custom replication agents
– Replicate data to relational or non-relational databases
Actions based on events
– When the price of ORCL increases by $1.00, notify other
applications to re-price options
– When a new subscriber is added, notify the billing and
provisioning systems
TimesTen Replication
TimesTen-to-TimesTen Replication
Replicate entire databases or
individual tables
Master - Subscriber Dynamic configuration with
SQL
Automatic recovery and
Master - Master catch-up of down systems
Asynchronous or synchronous
(dynamic configuration with
SQL)
Does not include a cluster
manager (no automatic
N-Way failover)
Replication – How It Works
(2) (7)
Bookmark
TimesTen
(1) Log
File
Rep. Agent
Data
Store Disk
Image
Sender (3) Ack. TCP/IP
Receiver changes (6) Transaction
(5) Bookmarks
TimesTen Log
File
Rep. Agent
Data
Store Disk
(4) Image
changes
TimesTen Cache
Connect
to Oracle
What you can do with Cache Connect
Load data from Oracle into Client
TimesTen
– Bulk load with LOAD CACHE App
GROUP, or …
ODBC/JDBC
– AUTOREFRESH replication
Save data from TimesTen to
Oracle Application
Server Tier
– Using a “FLUSH CACHE GROUP”
command in TimesTen SQL
Async
Once the data is loaded, your Writethrough
AUTO-
REFRESH
application connects to
TimesTen Hot Data Subset
– SQL Operations are executed on
TimesTen tables Database
ORACLE Server Tier
– Performance is greatly improved
Web-based GUI Administrator
Example SQL Statement
CREATE TABLE CMS_FLEET (
CMS_FLEET_TYPE CHAR(10) NOT NULL,
MAX_CREW_CNT NUMBER(3) NULL, Oracle table
ODS_CREATE_TMSTMP CHAR(26) NULL,
PRIMARY KEY (CMS_FLEET_TYPE)
schema
);
CREATE READONLY CACHE GROUP CG_CMS_FLEET
AUTOREFRESH MODE INCREMENTAL INTERVAL 60 SECONDS
FROM SCOTT.CMS_FLEET (
CMS_FLEET_TYPE CHAR(10) NOT NULL,
MAX_CREW_CNT SMALLINT, TimesTen Cache
PRIMARY KEY (CMS_FLEET_TYPE)) Group
WHERE FLEET_TYPE = ‘BOEING’;
A table called CMS_FLEET now exists in both TimesTen and Oracle:
SELECT MAX_CREW_CNT FROM SCOTT.CMS_FLEET
WHERE CMS_FLEET_TYPE = ‘767’;
Asynchronous Writethrough
App Memory and
TimesTen acts as a Disk Buffers
“write cache”
Good for applications with
TimesTen
sudden, high write demand Oracle Agent
spikes
Oracle
SELECT
Application Oracle Tables
Main TimesTen Benefits
Response Time in Microseconds
Predictable and Consistent Response Time
Throughput up to 100,000 Transactions Per
Second and Beyond
Familiar Relational Model – Existing
Developers are Immediately Productive
Unattended operation – DBA tasks are
automated with applications
High Availability through Replication
QUESTIONS &
ANSWERS
Higher Customer Satisfaction
through Personalization Dynamic
User preferences are loaded Personalization
from Oracle RAC into Oracle In-
Memory Database upon login Worldwide Corporate
Subscribers
Preference information is now NA Application EMEA / APAC
looked up in Oracle In-Memory Servers Application Servers
Database
HA through replication
One API for both databases Load Balancer
JDBC Load Balancer
(JDBC)
Fast response time means a 4-CPU
Servers,
better user experience Linux,
2 GB
Users now see personalized databases Standby Active Active Standby
pages suited to their needs
User experience is now Master Master
noticeably better than their Database Database
competitors Oracle
Hedge Fund: Unprofitable Architecture
Hedge-Fund Traders
Only the first trade makes a … Should I
profit make this
trade?
Customer could not analyze
data fast enough to make
the trade first
Model Model Model
Real-time ticker data could #1 #2
Home-Grown #N
Real-time
Modeling of
not be combined with In-Memory Database
… Current
INFLEXIBLE
historic data fast enough Market
vs. History
Enterprise RDBMS was not
fast enough
Real-time Market
Home-grown in-memory Enterprise Data Updates
data structures lacked SQL RDBMS
functionality and were Historic TOO SLOW
Market
expensive to maintain Data
Profitable, Faster, Real-Time Decisions
Hedge-Fund Traders
Oracle In-Memory Database
provides a flexible SQL …
interface allows for easy
aggregations of data
Combining real-time ticker
Model Model Model
data with historic data is #1 #2 #N
Real-time
Modeling of
FAST and EASY
… Current
Analysis of market data in Market
vs. History
sub-seconds, not minutes
The customer can make the Real-time Market Data Updates
trade first, before their
competitors Historic Enterprise
Therefore, they make a profit On-demand load Market RDBMS
of selected data Data
… and their competitor loses!
Oracle TimesTen Comparison
Characteristic Oracle 10g TimesTen
Applications Mission-critical Mission-critical
Model Relational Relational
Architecture Disk-centric Memory-centric
Performance driver Human interaction Computer to computer
Typical deployment Back-office server Embedded in
application
Response Times Milliseconds to Micro to milliseconds
seconds
Data Capacity Gigabytes - Terabytes Up to ~30 GB
Administration DBAs & Sys Admins Unattended operation