Hacker News Reader

Comment by randall | Hacker News Reader

I'm interested if @antirez has thought of extending the (admittedly fun) redis api to a disk-backed version for when you don't need the performance of in-memory, but appreciate the simplicity of the redis api.

Maybe be able to assign a specific DB number to disk?

I realize that might be kitchen sinking Redis more than he intends, but it might be worth it.

View on HN

As others have noted, this capability was intentionally removed. From http://redis.io/topics/virtual-memory

"Redis VM is now deprecated. Redis 2.4 will be the latest Redis version featuring Virtual Memory (but it also warns you that Virtual Memory usage is discouraged). We found that using VM has several disadvantages and problems. In the future of Redis we want to simply provide the best in-memory database (but persistent on disk as usual) ever, without considering at least for now the support for databases bigger than RAM. Our future efforts are focused into providing scripting, cluster, and better persistence."

I assume Instagram was a serious user of Redis. If you can switch from Redis to Cassandra in a matter of days, even after presumably years of Redis-usage being ground in your code base (because no matter how much you try to abstract out your fundamental data store, it always comes poking out in your architecture), it's probably not useful for Redis to try to out-Cassandra Cassandra. Let Redis be the best Redis it can be, and let Cassandra be the best Cassandra it can be.

We are still a very serious user of Redis, and I agree with this. Redis works well as a persisted networked heap, which very different from a database. IMHO Redis would have to trade off a lot of it's value to become a "real database."

The ArDb project might fill this gap "A redis-protocol compatible persistent storage server, support LevelDB/KyotoCabinet/LMDB as storage engine." https://github.com/yinqiwen/ardb

IIRC, antirez experimented with that for a version or two before deciding it wasn't right for redis, deprecating then removing those added features.

My understanding is that being single threaded and assuming that every operation will complete very quickly is how Redis sidesteps a lot of complexity around atomicity and transactions. This is probably why swap as an option was quickly removed.

I've been working on a server that implements the Redis protocol and stores the data in LevelDB: https://github.com/cupcake/setdb