Lessons Learned – Benchmarking NoSQL on the AWS Cloud (AerospikeDB and Redis)(lynnlangit.com)
lynnlangit.com
Lessons Learned – Benchmarking NoSQL on the AWS Cloud (AerospikeDB and Redis)
http://lynnlangit.com/2015/01/28/lessons-learned-benchmarking-nosql-on-the-aws-cloud-aerospikedb-and-redis/
3 comments
We've also added a few thoughts here: https://redislabs.com/blog/the-lessons-missing-from-benchmar...
I notice that 16 Redis shards have been used for no-persistence case. But only 12 Redis shards used for persistence case. Any reason for this?
In the first case (no-persistence) the bottleneck is the network throughput. In the second case the bottleneck is the disk IO.
We stopped adding more Redis shards as we reached the disk IO limit with the 12 shards. Adding more shards wouldn't affect the results as the disk was choking with the number of transactions from 12 shards.
We stopped adding more Redis shards as we reached the disk IO limit with the 12 shards. Adding more shards wouldn't affect the results as the disk was choking with the number of transactions from 12 shards.
Good to see Redis delivering the same performances of the other system in a benchmark conceived by the other systems creators. The benchmark is limited to GETs and SETs without pipelining, and the amount of data is not clear (or I missed it). However what's cool is that with pipelining in Redis you get 5x this at least, and the fact that at the same speed you can't just run GETs and SETs, but all the O(1) and O(log_N) operations.
Amount of data is mentioned: 10 million keys and 100 byte string values for each key
Yep I read this, but it looks strange because the instances have 250GB of RAM... more than one order of magnitude more of what Redis needs to store the same amount of data. So maybe there is something more about that? No idea.