How to choose an in-memory NoSQL solution: Performance measuring
highscalability.com
How to choose an in-memory NoSQL solution: Performance measuring
1–10 of 33 posts
Re: How to choose an in-memory NoSQL solution: Performance measuring
#2I'm quite surprised to see that there's no Aerospike in this comparison.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#3A couple of notes on usability:
Having the labels of the charts (i.e., the color to db matching) be defined only in one place (above the graphs) makes comparing the charts in the article really difficult to read and interpret.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#4I'm quite surprised to see that there's no Aerospike in this comparison.
Agreed. It's pretty trivial to overwhelm a Redis instance. For ad serving scenarios at high traffic scenarios Aerospike is really where it's at.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#5I'm quite surprised to see that there's no Aerospike in this comparison.
Agreed. It's pretty trivial to overwhelm a Redis instance. For ad serving scenarios at high traffic scenarios Aerospike is really where it's at.
Unlikely you are going to overwhelm Redis in a non-deterministic fashion. What do you even mean by overwhelm?
The post only concerns itself with in-memory workloads; I don't think Aerospike is competition in this space, while their advantage is against workloads working against SSD backed datasets. "After Google published a blog post “Cassandra Hits One Million Writes Per Second on Google Compute Engine” – using 300 nodes, we followed the same steps and documented how Aerospike Hits One Million Writes Per Second With Just 50 Nodes On Google Compute Engine. [...] Aerospike on SSD is very comparable to that of RAM. At 100% write, the SSDs are able to sustain 226,000 transactions per second compared to 239,000 for RAM." [0] Redis would have no problem hitting 250K IOPS on just a single core provided by GCE (or AWS EC2 or similar).
[0] http://www.aerospike.com/resource/aerospike-soars-in-the-goo...
Re: How to choose an in-memory NoSQL solution: Performance measuring
#6The hardware setup is not clear. Are you running YCSB client and the database on the same single A3 instance?
Re: How to choose an in-memory NoSQL solution: Performance measuring
#7Earlier quoted context omitted.
Agreed. It's pretty trivial to overwhelm a Redis instance. For ad serving scenarios at high traffic scenarios Aerospike is really where it's at.
Unlikely you are going to overwhelm Redis in a non-deterministic fashion. What do you even mean by overwhelm? The post only concerns itself with in-memory workloads; I don't think Aerospike is competition in this space, while their advantage is against workloads working against SSD backed datasets. "After Google published a blog post “Cassandra Hits One Million Writes Per Second on Google Compute Engine” – using 300…
Redis needs only two nodes on GCE to deliver 1M writes per second: https://redislabs.com/blog/nosql-bar-datastax-aerospike-couc...
Re: How to choose an in-memory NoSQL solution: Performance measuring
#8I'm quite surprised to see that there's no Aerospike in this comparison.
Obligatory mention:
Re: How to choose an in-memory NoSQL solution: Performance measuring
#9I'm quite surprised to see that there's no Aerospike in this comparison.
Agreed. It's pretty trivial to overwhelm a Redis instance. For ad serving scenarios at high traffic scenarios Aerospike is really where it's at.
A single Redis instance uses a single CPU core so yeah, hitting the its limits (no matter how high) is always a possibility. OTOH, there's always the possibility for sharding and clustering a Redis database to scale it up 'n out, thus making "overwhelming" it less trivial.
Re: How to choose an in-memory NoSQL solution: Performance measuring
#10I'm quite surprised to see that there's no Aerospike in this comparison.
Similarly, I was hoping to find VoltDB in the mix.