Instagram: Making the Switch to Cassandra from Redis (opens in new tab)

I'm not entirely sure what I'd search for so I figure I might as well ask here. When a key won't fit in redis, does redis remove the least active key(s) to make room? And is there a way to persist the removed keys to disk to possibly be retrieved at a later date? That way the most active keys remain in memory while the least active keys are still available.

The cost of VM RAM is bounded below by the cost of the physical RAM used to provide it, unless it's subsidized by costs elsewhere.

I think that's a very important point. It's not saying that X is better than Y, it's just for these particular use cases, one tool is better suited than the other tool because of which problems they were designed to tackle.

Awesome interview and kudos to whoever recommended the switch, that's a ton of savings you guys made!

I was thinking the same thing.

"We are very happy with the hammer we are currently using. Previously, we were using pliers to hammer nails and we saw that it wasn't very efficient."

According to the article, the interviewee used to work at DataStax (leader in Cassandra) before joining Instagram. I guess this is one of the reason why they first considered Cassandra and it turned out to be very successful. Biased or not, it is always good to have an engineer with deep understanding on the database, rather than just being an ordinary user.

Exactly the point I was thinking

I'd tend to think if it ain't broke don't fix it.

Apparently Facebook is not using Cassandra much. For their messaging project they ended up with HBase instead of Cassandra [1]. I don't know if the system replaced the earlier Cassandra system, or complemented it.

[1] http://nosql.mypopescu.com/post/1583884165/facebook-the-unde...

I assure you it did not.

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.

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

You might be interested in this:

http://www.anchor.com.au/blog/2013/04/redis-rethought-exciti...;

http://github.com/inaka/edis is here now for that purpose