

Instagram: Making the Switch to Cassandra from Redis - dikbrouwer
http://planetcassandra.org/blog/post/instagram-making-the-switch-to-cassandra-from-redis-75-instasavings

======
antirez
I think that here the approach is very wise: every time you have a problem
involving a big amount of data, Redis may be costly, since it stores data in
memory. Sometimes this is unavoidable, for instance I may see Twitter
switching from Redis to another in-memory store to cache timelines, but hardly
to something using disk. So it is very legit to say, I'm running a number of
hosts since my memory requirements are high, let's try a cheaper on disk
solution.

However that said it is also true that memory starts to be _seriously_ cheap,
and the real limit may be to run stuff on EC2 or similar platforms.

So sometimes the cost of RAM is a virtual cost associated with the platform
you are running your services in, compared to the actual cost of that amount
of memory.

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

~~~
ricardobeat
I haven't actually experienced this, someone correct me if I am wrong: you can
choose from different policies (LRU, TTL, random) to expire/remove keys,
otherwise if you disable maxmemory it will start using the OS virtual memory
and slow down.

Redis had a virtual-memory option like you describe at some point, but it was
scraped due to poor performance and other issues.

~~~
tfb
Ah LRU and virtual memory are the keywords I was looking for. I couldn't
remember! Thanks!

------
rbranson
Just to be clear -- this doesn't mean we have eliminated Redis. It's still a
very useful tool.

~~~
smaili
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!

------
ozgurcayci
The article compares Redis to Cassandra which means comparing apples to
oranges for their use case. It would have been meaningful if they explained
why they chose Casssandra, instead of for example Hbase.

~~~
scribu
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."

------
brown9-2
Interesting that Instagram is still (at least partially) on EC2 rather than in
Facebook's datacenters.

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

------
ma2rten
I wonder if being part of Facebook (from which Cassandra originated) has
anything to do with the choice for Cassandra over other databases.

~~~
lobster_johnson
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...](http://nosql.mypopescu.com/post/1583884165/facebook-the-underlying-
technology-of-messages-using)

~~~
zht
It has been replaced entirely

[1] [https://www.facebook.com/notes/facebook-
engineering/inside-f...](https://www.facebook.com/notes/facebook-
engineering/inside-facebook-messages-application-server/10150162742108920)

------
randall
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.

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

~~~
rbranson
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."

