TimesTen Technology For Epoch Well

1
TimesTenTechnology For Epoch Well

• March 16, 2006

2
TimesTen In-Memory Database History and
Technology Background
3
When You Think Database
SQL
Results
RDBMS client/server connectivity NOT fast
enough for a new category of performance-intensive
applications
4
RDBMS with Home-Grown Cache
SQL
Results
For very demanding applications Build a
home-grown, application-specific, in-memory
cache.
5
Combine the cache and the database into ONE
product
SQL
RDBMS
SQL
Results
Full capabilities of a relational database
Memory-optimized speed latency Optimized for
embedded architecture Persistent, recoverable,
highly available
6
History of TimesTen

• Early 1990s 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

7
1,500 Customers Run TimesTen

• 7 of the top 9 NEPs build products with
  TimesTen
• The worlds 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 the Enterprise
In Telecom
On Wall Street
In Networks
8
Real-Time Program Trading of Equities
Lehman Brothers
Fixed-Income Trading System
Internal Trading Desks( different geographyor
class of instrument )

• TimesTen Usage
• Event capture (trade orders)
• Order processing (trade matching)
• Event publishing (trader alerts and closed
  orders)
• Performance Metrics
• 1,000 fixed-income trades/hr (30/sec peak)
• 20 trader alerts/sec
• Configuration
• 4-CPU Server (plus hot-standby) per location
• Linux with C applications
• 2 Gigabyte TimesTen
• Value of TimesTen
• Fast order execution
• Trader alerting

Orders, Inquiries, Notifications
Trader Alerts
XLA Application
XLA Application
Closed Order Data
Tibco Messaging
AggregatedReporting
Global Order Repository
9
TimesTen In-Memory Database Technology
Introduction
10
TimesTen Technology Basics

• High-performance in-memory database software
• Optimized memory layout and algorithms
• Flexible options for data persistence to disk
• Applications access the database via standard
  APIs (SQL,ODBC, JDBC)
• Protect, Extend, Evolve your existing investment
  in RDBMS

TimesTen
Disk Persistence/ Recovery
11
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
• 64-bit operating systems
• Limit is available RAM
• For larger databases, use TimesTen to cache
  Oracle data

One Shared Memory Segment
Disk Persistence
12
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 (3264)
• HP Tru64 (64 bit)
• IBM AIX 5.3 POWER (32 bit and 64 bit)
• Windows 2000, XP, Server 2003 (32 only)

13
TimesTen Architecture
14
TimesTen Architecture
TimesTen Main Daemon
Directly Connected Applications
TimesTen Subdaemon
TimesTen Subdaemon
TimesTen Subdaemon
TimesTen Subdaemons
Engine (ODBC Driver) Database I/O
Data in Shared Memory
Disk Persistence
15
Client/Server Connections to a Data Store
Direct Connect Application
TimesTen Server
Client Application
TimesTen Engine (ODBC Driver)
TimesTen Client Driver(ODBC or JDBC Driver)
TCP/IP
Data Store in Shared Memory
16
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

TimesTen Main Daemon
Directly Connected Applications
17
Architecture Comparison
18
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

19
TimesTen Performance
20
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
21
Lightning Fast Response
Average Response Times
TimesTen/DataServer 5.1 Sun Solaris 9, 1.6 GHz
Sparc
45
37µs
36µs
40
35
Updatea Record
Inserta Record
30
15µs
25
Microseconds
INSERT
UPDATE
20
Capture or update data in 40 millionths of a
second
15
Retrieve a Record
SELECT
10
5
0
Database Operation
22
ODBC, JDBC, Client/Server
100 Read, 4-CPU Xenon x86 3/0 GHz, Linux
4-CPU 2.8 GHz Linux
271,000
Direct
Client/Server
171,000
Transactions Per Second
51,000
35,000
JDBC
ODBC with C or C
23
Data Durability Recovery
24
ACID Properties

• Full support for transactions (COMMIT/ROLLBACK)
• Row-Level Locking
• Versioning
• Writes do not block reads
• Reads do not block writes

25
Durability Disk Storage
Hard Disk
Non-blocking Checkpoint
Datastore.ds0
Datastore.ds1
CALL ttCkpt
TimesTen Subdaemon
Datastore.log1
Datastore.log2
Logging
Datastore.log3
Checkpoints are performed automatically ONLY in
TimesTen 6.0 and above
26
Three Logging Types
Dynamically configurable with SQL statements
LOG BUFFER .. Tx ... Tx ...Tx
Hard Disk
TimesTen Data Store
In-Memory Logging
Datastore.ds0
Buffered Logging
LOG BUFFER .. Tx ... Tx ...Tx
TimesTen Data Store
Datastore.ds1
Datastore.log1
Datastore.log2
LOG BUFFER COMMIT COMMIT COMMIT
Datastore.log3
TimesTen Data Store
Durable Commit
27
TimesTen Data Store Recovery
Datastore.ds0
Datastore.ds1
Datastore.log1
TimesTen Subdaemon
TimesTen Data Store
Datastore.log2
Datastore.log3
2. Transaction Log Rollforward
28
TimesTen Advanced Features and Functionality
29
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

30
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

31
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

32
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

33
TimesTen Replication
34
TimesTen-to-TimesTen Replication

• Replicate entire databases or individual tables
• Dynamic configuration with SQL
• Automatic recovery and catch-up of down systems
• Asynchronous or synchronous (dynamic
  configuration with SQL)
• Does not include a cluster manager (no automatic
  failover)

Master - Subscriber
Master - Master
N-Way
35
Replication How It Works
(7)
(2)
Bookmark
(1)
TimesTen
Log File
Rep. Agent
Data Store
Disk Image
(3)
Ack.
Sender
TCP/IP
(6)
changes
Receiver
(5)
TimesTen
Log File
Rep. Agent
Data Store
Disk Image
(4)
changes
36
TimesTen Cache Connect to Oracle
37
What you can do with Cache Connect

• Load data from Oracle into TimesTen
• Bulk load with LOAD CACHE GROUP, or
• AUTOREFRESH replication
• Save data from TimesTen to Oracle
• Using a FLUSH CACHE GROUP command in TimesTen
  SQL
• Once the data is loaded, your application
  connects to TimesTen
• SQL Operations are executed on TimesTen tables
• Performance is greatly improved

Client
App
ODBC/JDBC
Application Server Tier
Async Writethrough
AUTO- REFRESH
Hot
Data Subset
Database Server Tier
ORACLE
38
Web-based GUI Administrator
39
Example SQL Statement
CREATE TABLE CMS_FLEET ( CMS_FLEET_TYPE
CHAR(10) NOT NULL, MAX_CREW_CNT
NUMBER(3) NULL, ODS_CREATE_TMSTMP
CHAR(26) NULL, PRIMARY KEY
(CMS_FLEET_TYPE) )
Oracle table 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, PRIMARY KEY (CMS_FLEET_TYPE))
WHERE FLEET_TYPE BOEING SELECT
MAX_CREW_CNT FROM SCOTT.CMS_FLEET WHERE
CMS_FLEET_TYPE 767
TimesTen Cache Group
A table called CMS_FLEET now exists in both
TimesTen and Oracle
40
Asynchronous Writethrough
Memory and Disk Buffers
App
TimesTen acts as a write cache Good for
applications with sudden, high write demand
spikes
TimesTen Oracle Agent
Oracle Application
SELECT
Oracle Tables
41
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

42
A
43
Higher Customer Satisfaction through
Personalization
Dynamic Personalization

• User preferences are loaded from Oracle RAC into
  Oracle In-Memory Database upon login
• Preference information is now looked up in Oracle
  In-Memory Database
• HA through replication
• One API for both databases (JDBC)
• Fast response time means a better user experience
• Users now see personalized pages suited to their
  needs
• User experience is now noticeably better than
  their competitors

Worldwide Corporate Subscribers
NA Application Servers
EMEA / APAC Application Servers
JDBC
Load Balancer
Load Balancer
4-CPU Servers, Linux, 2 GB databases
Active
Standby
Standby
Active
Master Database
Master Database
Oracle
44
Hedge Fund Unprofitable Architecture
Hedge-Fund Traders

• Only the first trade makes a profit
• Customer could not analyze data fast enough to
  make the trade first
• Real-time ticker data could not be combined with
  historic data fast enough
• Enterprise RDBMS was not fast enough
• Home-grown in-memory data structures lacked SQL
  functionality and were expensive to maintain

Should I make this trade?

Real-time Modeling of Current Market vs. History
Home-Grown In-Memory Database INFLEXIBLE

Real-time Market Data Updates
Enterprise RDBMS
Historic Market Data
TOO SLOW
45
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 data with historic
  data is FAST and EASY
• Analysis of market data in sub-seconds, not
  minutes
• The customer can make the trade first, before
  their competitors
• Therefore, they make a profit and their
  competitor loses!

Real-time Modeling of Current Market vs. History

Real-time Market Data Updates
Enterprise RDBMS
Historic Market Data
On-demand load of selected data
46
Oracle TimesTen Comparison