On the other hand, Redis was probably born 10 years ahead of its time. If and when we finally get to mass-produce persistent storage media with the speed of RAM and the capacity of HDD -- SSDs are getting there, but not quite yet, and we don't know when memristors will become commercially available -- Redis will be the most obvious database to run on it.
I can tell you that we tried to make MongoDB do high write updates, and a 24 server cluster (8 shards with 2 replicas per shard) was unable to keep up due to the massively slow response times.
I replaced it with a single server running a twemproxy cluster of 4 redis instances and that single server was able to handle more than 10x the load.
So, there are many cases where using redis makes a lot more sense, even if it makes it complicated to maintain a persistence model.
> These are the two primary reasons Redis sucks as a primary store:
> You have to be able to fit all your data in memory, and
> If your server fails between disk syncs you lose anything
> that was sitting in memory.
It’s summary is:
Edis is a protocol-compatable Server replacement for Redis, written in Erlang. Edis's goal is to be a drop-in replacement for Redis when persistence is more important than holding the dataset in-memory.
And so I don’t have to hijack this thread a discussion: