Since we shared our YCSB Benchmark Results for YugaByte and Apache Cassandra, we received great interest and feedback. The suggestions we received are:
- share 99th percentile (P99) latencies.
- run Apache Cassandra with Java G1 garbage collector and a smaller heap size.
We just did that and want to share the new results.
Setup
- 3-node cluster in Google Compute (GCP)
- Each node is a n1-standard-16
- 16 vcpu’s, Intel® Xeon® CPU @ 2.20GHz CPUs
- 60GB RAM
- 2 x 375 GB direct attached SSD
- Replication Factor = 3
- YugaByte: default configuration parameters were used.
- Apache Cassandra: 3.11.1 release. Non-default configuration parameters:
- Garbage collector = G1GC
- MAX_HEAP_SIZE = 12GB
- For writes:
- YugaByte uses Raft (a distributed consensus) protocol for strong consistency.
- With Apache Cassandra, quorum write setting was used.
- For reads:
- YugaByte reads default to strongly consistent reads.
- With Apache Cassandra, quorum read setting was used.
- YCSB client software was built from a fork of the open source repository. This time we further improved the use of “prepared” statements in the Cassandra binding (Git commit 5a42b2cec46cefc2cce61b938a92073af154c1e7).
- YCSB maxexecution for each workload was set to 1 hour.
Results
The benchmark was done for each system with 1 million, 5 million and 10 million keys. Again, we observed that YugaByte’s throughput outperformed Apache Cassandra’s by increasing margins as the number of keys (data density) increased.
In addition, we saw that YugaByte’s P99 latencies were markedly lower than Apache Cassandra’s, despite compactions running in the background. As noted in our earlier post on YugaByte DB P99 latencies with Netflix Data Store Benchmark, YB’s lower latencies are primarily due to better architecture for strong consistency (no quorum reads, no anti-entropy/read-repairs) and implementation in C++ (no Java garbage collection pauses).
