X

TimesTen In-Memory Database
for Extreme Performance

How fast is Oracle TimesTen Velocity Scale?

Doug Hood
TimesTen Cloud Product Manager

Oracle TimesTen Velocity ScaleOracle TimesTen Velocity Scale is based on a foundation of the TimesTen In-Memory Database. TimesTen has very low latency for SQL operations which are measured in microseconds.

TimesTen Latency is measured in Microseconds not milliseconds

 

It is hard to make apples-to-apples comparisons between databases as there are so many variables. When DB vendors benchmark each others products, there is always the suspicion that the competitors DB is not tuned optimally. The following is an example of an apples-to-apples DB benchmark:

In August 2016, Google published an OLTP DB benchmark for a high availability configuration between two Availability zones using the Sysbench DB read/write workload. Google optimized Google Cloud SQL Second Generation in Google Cloud and Google ran Amazon RDS MySQL and Aurora on AWS. A consulting firm (2ndWatch.com) soon re-ran the benchmarks showing that Amazon Aurora was not tuned optimally. 2ndWatch [with consulting from Amazon] was able to show that AWS Aurora was able to outperform Google Cloud SQL Second Generation. This meant that the DB vendors rather than Oracle verified that their databases were optimally tuned for this benchmark.

As this Sysbench read/write DB is doing synchronous replication between two availability zones [data centers], the network round trip time was the dominant factor for TimesTen Velocity Scale.


Sysbench throughput
 
The variables in the above throughput benchmark were the RDBMS and the public Clouds. The following is the latency [smaller is better] for the same Sysbench benchmark.
 
Sysbench latency

 

As you can see, TimesTen Velocity Scale has the lowest latency and highest throughput. Google Cloud SQL Second Generation, Amazon RDS MySQL and Amazon Aurora all use an active/standby replication configuration. Even though they can add more read-only replicas to help read scaling, their write throughput is limited by their single active database. Oracle TimesTen Velocity Scale uses an active/active replication architecture which enables write scaling by adding more machines to the Velocity Scale database.

The following OLTP benchmark shows read/write scaling using the TPTBM benchmark. This workload is doing 80% reads and 20% writes.

 

147 Million TPS for an 80$ read and 20% write TPTBM workload

 

This benchmark shows linear scaling for the TPTBM read/write workload using 32 Sun X5-2 Linux x8664 machines on the Oracle Bare Metal Cloud. As persisting the committed write transactions was the bottleneck, we used two instances of Velocity Scale per machine, so there were 64 Velocity Scale nodes running on 32 machines.

Given the write IO bottleneck, we re-ran the test with a 100% read workload. The result was 1.2 Billion PK SQL Selects per second using 64 machines.

 

1.2 Billion SQL PK reads per second

 

This 100% read only workload shows linear scalability to 64 Sun X5-2 Linux machines using the Oracle Bare Metal Cloud. We look forwards to the opportunity to repeat these tests with more and faster machines.

For more details, come to Oracle Open World 2017.

Disclaimer: these are my personal thoughts and do not represent Oracle's official viewpoint in any way, shape, or form.

 

Be the first to comment

Comments ( 0 )
Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.Captcha