safe harbor statement - nocougnocoug.org/download/2016-11/nocoug_201611_hood_times_ten_vel… ·...

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. |

Safe Harbor Statement

The following is intended to outline our general product direction. It is intended for information purposes only, and may not be incorporated into any contract. It is not a commitment to deliver any material, code, or functionality, and should not be relied upon in making purchasing decisions. The development, release, and timing of any features or functionality described for Oracle’s products remains at the sole discretion of Oracle.

2


The Next Generation of In-Memory Database Oracle TimesTen Velocity Scale In-Memory Database

Doug Hood TimesTen Product Manager

November 17, 2016


Agenda

Introduction to TimesTen

TimesTen Velocity Scale In-Memory Database

Demo

4

1

2

3


20 Years of Extreme Performance

• 1998 First commercial In-Memory RDBMS

• HA Replication • Online Upgrades • Application-tier Cache

for Oracle Database

• PL/SQL and OCI Support • Oracle Clusterware Integration • Cache Grid for Scale Out • ODP .NET Support • BLOB, CLOB, NCLOB data types

• Parallel Replication • In-Memory Analytics • Columnar Compression • Index Advisor • Oracle R Support • In-Memory Star Join • Oracle Golden Gate Integration

Oracle TimesTen – Pure In-Memory Relational Database

• Parallel data import from Oracle Database

• Parallel database restart • Highly concurrent range

indexes • Parallel Replication with

commit order optimization

• Oracle RAC integration • National Language Support • Oracle Data Types support • SQL Developer Integration • Enterprise Manager integration

5

TimesTen 6

TimesTen 7

Pre-Oracle acquisition TimesTen 11g

11.2.1

TimesTen 11g

11.2.2

TimesTen 11.2.2.x

Enhancements

1996 |

2005

2006 |

2008

2009 |

2011

2012|

2013

2014 |

2016


Relational Database

– Pure in-memory

– ACID compliant

– Standard SQL

– Entire database in DRAM

Persistent and Recoverable – Database and Transaction logs

persisted on local disk or flash storage

– Replication to standby and DR systems

6

Extremely Fast – Microseconds response time

– Very high throughput

Highly Available – Active-Standby and multi-master

replication

– Very high performance parallel replication

– HA and Disaster Recovery

Oracle TimesTen In-Memory Database


Low Latency - Microseconds Response Time Performance – Response Time

Millionths of a

Second

Millionths of a

Second

7

TPTBM Read and Update E5-2699 v4 @ 2.20GHz

2 socket, 22 cores/socket,

2 threads/core TimesTen 11.2.2.8.0 (100M rows, 17GB)

1.64

5.06

0.00

1.00

2.00

3.00

4.00

5.00

6.00

SELECT Query UPDATE Transaction

Mic

rose

con

ds


Performance - Throughput 5.6 Million Transactions Per Second

8

TPTBM Mixed Workload

(80%R-10%U-5%I-5%D) E5-2699 v4 @ 2.20GHz

2 socket, 22 cores/socket,

2 threads/core TimesTen 11.2.2.8.0 (100M rows, 17GB)

5,619,403

0

1,000,000

2,000,000

3,000,000

4,000,000

5,000,000

6,000,000

1 2 4 8 12 16 20 24

Tran

sact

ion

s P

er S

eco

nd

Concurrent Processes

5.6 Million Transactions Per Second


Most Widely Used Relational In-Memory Database Deployed by Thousands of Companies

9




Demo

10

1

2

3


Oracle TimesTen Velocity Scale In-Memory Database

• Scale-out, shared nothing architecture

• Data location transparency

• Built-in high availability via K-safety

• Elastic scalability

• Easy to deploy and manage

• Easy application development for OLTP workloads

• Supports analytic workloads

• On-premises or Cloud deployment

11

Single Image In-Memory Database


Database Element

• Each Element has its own set of checkpoint files and transaction log files for persistence

• The Element is the smallest unit for database persistence, failure recovery and high availability

Element <n>

Tx Logs

Checkpoints

Database Element

12

Unit of Persistence and Recovery

Single Image In-Memory Database


Single Database Image

• Database size not limited by memory

• Table data distributed across all elements – All elements are equal

• Connect to any element and access all data – Distributed queries, joins & transactions

• No need to de-normalize data model

13


Data Distribution Methods

• Distribute by Hash – Primary key or user-specified columns

– Consistent hash algorithm

– Examples: Customers, Subscribers, Accounts

• Distribute by Reference – Co-locate related data to optimize joins

– Based on FK relationship

– Supports multi-level hierarchy

• Distribute by Duplicate

– Identical copies on all elements

– Useful for reference tables

– Read and join optimization

Customer

Distribute by Hash

Distribute Table Data by Hash, Reference or Duplicate

Element 1

0 David

4 Igor

8 Tim

Element 2

1 Bill

5 Sam

9 Charles

Element 3

2 Olaf

6 Henri

10 Jie

Element 4

3 Chi

7 Simon

11 Chris

Distribute by Reference

Order

1 0 16/6/15

6 8 16/3/22

2 5 16/2/22 5 6 16/5/10 3 3 16/3/1

4 11 16/2/5

phone 100

tablet 200

watch 300

phone 100

tablet 200

watch 300

phone 100

tablet 200

watch 300

phone 100

tablet 200

watch 300

Products

Distribute by Duplicate

14


High Availability and Maximum Throughput

• Built-in HA via multiple copies of the data (K-safety)

– Automatically kept in sync

• All replicas are active for reads and writes

– Double the compute capacity

• Transactions can be initiated from and executed on any replica

K-Safety, All Active

A

A

B

B

C

C

D

D

15


Database Fault Tolerance – No Application Down Time Provided one entire copy of the database is available

• If multiple elements fail, applications will continue provided there is one complete copy of the database

• Recovery after failure is automatic • If an entire replica set is down,

application can explicitly choose to accept partial results

16


Elastic Scalability

Adding and removing DB elements

- Data automatically redistributed to new elements

- Workload automatically uses the new elements

- Connections will start to use new elements

- Throughput increases with added compute resources

Expand and shrink the database based on business needs

17

E

E

B

A

C

A

B

C

D

D


Deployment and Management

• Single point of configuration and deployment

- Management instance(s)

• Powerful command line tools

- ttGridAdmin and ttGridRollout

• Extensive support in SQL Developer as well

- Velocity Scale grid rollout, monitoring and management

- SQL and table editor support

- Data loading

Single point of Control, via command line or SQL Developer

18


• Myth 1: You need a NoSQL DB to scale

• Myth 2: You need to abandon ACID txns to scale

• Myth 3: You need to de-normalize [no joins] to scale

• Myth 4: You need to manually shard your DB to scale

• Myth 5: You need to re-write your apps to scale

19

• Velocity Scale is proof that these myths are false

• Velocity Scale offers performance without compromise

Common Database Performance Myths


TimesTen Velocity Scale IMDB vs Cassandra

YCSB N*10M Rows Servers: 12 x X5-2 Clients: 2 x ODA

Network: 10Gbps

YCSB (Yahoo Cloud Service Benchmark) – 50% reads 50% writes [Workload A]

20

0

200,000

400,000

600,000

800,000

1,000,000

1,200,000

1,400,000

2x1 4x1 6x1 8x1 10x1 12x1

Op

era

tio

ns

pe

r se

con

d

Configuration (NxK)

Cassandra TimesTen Velocity Scale


TimesTen Velocity Scale IMDB vs Cassandra


Network: 10Gbps

YCSB (Yahoo Cloud Service Benchmark) – 95% reads 5% writes [Workload B]

0

200,000

400,000

600,000

800,000

1,000,000

1,200,000

1,400,000

1,600,000

1x2 2x2 3x2 4x2 5x2 6x2

Op

era

tio

ns

pe

r se

con

d

Configuration (NxK)

Cassandra TimesTen Velocity Scale

21

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | 22


Network: 10Gbps 0

1000

2000

3000

4000

5000

6000

7000

8000

9000

2x1 4x1 6x1 8x1 10x1 12x1

Late

ncy

(u

s)

Average Read Latency

TimesTen

Cassandra

TimesTen Velocity Scale IMDB vs Cassandra YCSB (Yahoo Cloud Service Benchmark) – 95% reads 5% writes [Workload B]

Copyright © 2016, Oracle and/or its affiliates. All rights reserved. | Oracle Confidential – Internal/Restricted/Highly Restricted 24

VelociScale DB – Recalc priority Flow

0

10

20

30

40

50

60

Bryce 1x2 2x2 3x2 4x2 5x2

Complex Update Txn (9 table join, hundreds of millions of rows)

Late

ncy

(Se

c)

Number of x5-2 machines

1x1 11.2.2.8

Latency - smaller is better

TimesTen 11.2.2.8 TimesTen VelociScale DB


Application Development

SQL

PL/SQL

Languages C/C++/C#

ODBC

ttClasses

OCI, Pro*C

ODP.NET

J2EE App Servers OR Mapping Java/JDBC

Oracle Confidential - Highly Restricted

Coming soon:

http://images.google.com/imgres?imgurl=http://www.jboss.com/company/logos/jboss_inc_logo.jpg&imgrefurl=http://www.jboss.com/company/logos&h=474&w=765&sz=20&hl=en&start=1&um=1&tbnid=jjc3R5dAxcvq-M:&tbnh=88&tbnw=142&prev=/images?q=jboss+logo&svnum=10&um=1&hl=en&sa=N


Developing Applications for Velocity Scale - Existing RDBMS and TimesTen skills apply

- Same SQL, same APIs, same languages

- No application code changes needed for existing TimesTen applications

- Need to consider table distribution types

- Hash may not be optimal for all cases

- Use Index Advisor and MVs if SQL joins are the bottleneck

26




Demo

27

1

2

3


Oracle TimesTen Velocity Scale In-Memory Database • Scale-out, shared nothing architecture with single database image

• Data location transparency

• Built-in high availability via K-safety

• Elastic scale-out

• Easy to deploy and manage

• Easy application development for OLTP and Analytic workloads

• On-premises or Cloud deployment

• You can have all of elastic scalability, HA, high performance, ACID transactions, full consistency and full featured SQL

28

safe harbor statement - nocougnocoug.org/download/2016-11/nocoug_201611_hood_times_ten_vel… ·...

Documents