

Lessons Learned – Benchmarking NoSQL on the AWS Cloud (AerospikeDB and Redis) - jeffbarr
http://lynnlangit.com/2015/01/28/lessons-learned-benchmarking-nosql-on-the-aws-cloud-aerospikedb-and-redis/

======
antirez
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.

~~~
chetanv
Amount of data is mentioned: 10 million keys and 100 byte string values for
each key

~~~
antirez
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.

------
itamarhaber
We've also added a few thoughts here: [https://redislabs.com/blog/the-lessons-
missing-from-benchmar...](https://redislabs.com/blog/the-lessons-missing-from-
benchmarking-nosql-on-the-aws-cloud-aerospikedb-and-redis)

------
ashweta
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?

~~~
lynnlangit
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.

