Oracle NoSQL Database Performance Tests

Our colleagues at Cisco gave us access to their Unified Computing and Servers (UCS) labs for some Oracle NoSQL Database performance testing.  Specifically, they let us use a dozen C210 servers for hosting the Oracle NoSQL Database Rep Nodes and a handful of C200 servers for driving load.

The C210 machines were configured with 96GB RAM, dual Xeon X5670 CPUs (2.93 GHz), and 16 x 7200 rpm SAS drives.  The drives were configured into two sets of 8 drives, each in a RAID-0 array using the hardware controller, and then combined into one large RAID-0 volume using the OS.  The OS was Linux 2.6.32-130.el6.x86_64.

Cisco 10GigE switches were used to connect all the machines (Rep Nodes and load drivers).

We used the Yahoo! Cloud System Benchmark as the client for the tests.  Our keysize was 13 bytes and the datasize 1108 bytes (that's how our serialization turned out for 1K of data).  We ran two phases: a load, and a 50/50 read/update benchmark.  Because YCSB only supports a Java integer's worth of records (2.1 billion), we created 400 million records per NoSQL Database Rep Group.  The "KVS size" column shows the total number of records in the K/V Store followed by the number of rep groups and replication factor in ()'s.  For example, "400m(1x3)" means 400m total records in a K/V Store consisting of 1 Rep Group with a Replication Factor of 3 (3 Replication Nodes total).

The clients ran on the C200 nodes, which were configured with dual X5670 Xeon CPUs and 96GB of memory, although really only the CPU speed matters on that side of the equation since they were not memory or IO bound.  Typically, we ran with 90 client threads per YCSB client process.  In the table below, the total number of client processes is shown in the "Clients" column, and at 90 threads/client (in general), the total client threads is shown in the "Total Client Threads" column.

The Oracle NoSQL Database Rep Node cache sizes were configured such that the B+Tree Internal Nodes fit into memory, but the leaf nodes (the data) did not.  Specifically, we configured them with 32GB of JVM heap and 22GB of  cache.  Therefore, the 50/50 Read/Update results are showing a single I/O per YCSB operation. The Durability was the NoSQL Database recommended (and default) value of no_sync, simple_majority, no_sync. The Consistency that we used for the 50/50 read/update test was Consistency.NONE.

Insert Results

KVS size 

Clients Total Client Threads
Time (sec)
Throughput (inserts/sec)
Insert Avg Latency (ms)
95% Latency (ms)
99% Latency (ms)
 400m(1x3)  3  90 15,139 26,498  3.3 5 7
 1200m(3x3)  3  270 16,738 71,684  3.6 7
11
 1600m(4x3)  4  360 17,053 94,441  3.7 7 18

50/50 Read/Update Results

KVS size

Clients Total Client Threads Total Throughput
Avg Read Latency
95% Read Latency
99% Read Latency
Avg Update Latency 95% Update Latency 99% Update Latency
millions
processes

 ops/sec  ms  ms  ms  ms  ms  ms
400m(1x3)
3
 30  5,595  4.8  13  50  5.6  13  52
1200m(3x3)
3
 270  17,097  4.0  13  53  5.7  15  57
1600m(4x3)
4
 360  24,893  4.0  12  43  5.3  14  51


The results demonstrate excellent scalability, throughput, and latency of Oracle NoSQL Database.

I want to say "thank you" to my colleagues at Cisco for sharing their extremely capable hardware, lab, and staff with us for these tests.


Comments:

What a great entry!
By the way, in the table of "50/50 Read/Update Results", you wrote that total client threads at 400m(1x3) was 30, but I suppose the value is 90.

Posted by guest on January 12, 2012 at 07:55 PM EST #

Yes, others have noted that. The correct number is in fact 30.

Posted by Charles Lamb on January 13, 2012 at 07:06 AM EST #

Is there a Comparison test available between Oracle-NoSQL and Vertica?

Posted by guest on January 11, 2013 at 04:28 PM EST #

Hi Charles am trying the same thing which you have done can you tell me how i can increase the default heap size and cache size for oracle nosql

Posted by guest on October 09, 2013 at 04:48 AM EDT #

Hello,

You would use the change-policy command when you configure the store. You can either do

change-policy -params "javaMiscParams= -Xmx..."

to change the JVM heap size or

change-policy -params "configProperties=je.xxx NN; je.yyy NN; ...;"

to change JE params.

Charles

Posted by Charles Lamb on October 09, 2013 at 09:32 AM EDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Anything related to Oracle NoSQL Database and/or Berkeley DB Java Edition.

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today