Throughput improvement is nice but not game-changing. What I would be more interested in here is a comparison of the longest latency. One problem my former employer had in a large Cassandra deployment was GC pause times causing latency spikes exceeding SLAs for a critical service. They did eventually tune the cluster to avoid these issues but to be honest it kind of shook my faith in any JVM-based database (maybe unfairly).
Hi @jeremyjh - you are absolutely correct about p99 being more important than avg latency for critical services.
We have done the following p99 measurements:
- a p99 comparison of YugaByte vs Cassandra using YCSB
- ran ndbench for a week and looked at the p99 of YB
The results are looking really good for YugaByte in both cases. We are going to post that very soon to our forum, will x-post here as well.
In gist, we ran ndbench for 7 days and our p99 was under 6 ms with no "long tail". It is achieved by cautious architectural design and implementation choices. More details are available in our post.
In our new benchmark run, we set up Apache Cassandra using G1 GC and a smaller heap size as suggested. Still, we observed a multitude of differences in throughput and p99 latencies in YugaByte over Apache Cassandra.
They managed to tune it to an acceptable level in our use case but we’d still see 50ms variation in the long tail responses. I think there are applications for whom that wouldn’t be acceptable. Like I said - it may not be fair but the impression I walked away with is that I don’t want GC in my database.
GC development is not standing still. Oracle claims sub 10ms pause times and terabyte heaps their new ZGC. And there are good pauseless or almost pauseless alternatives from other vendors as well.
