It also depends on you SLA, it should work for 99% of the time. But one GC/flush/compact could screw things up big time if you have tight SLA.
From: Drew Kutcharian <firstname.lastname@example.org>
Sent: Wednesday, March 6, 2013 9:32 AM
Subject: Re: Cassandra instead of memcached
I think the dataset should fit in memory easily. The main purpose of this would be as a store for an API rate limiting/accounting system. I think ebay guys are using C* too for the same reason. Initially we were thinking of using Hazelcast or memcahed. But Hazelcast (at least the community edition) has Java gc issues with big heaps and the problem with memcached is lack of a reliable distribution (you lose a node, you need to rehash everything), so I figured why not just use C*.
If your writing much more data then RAM cassandra will not work as fast as memcache. Cassandra is not magical, if all of your data
fits in memory it is going to be fast, if most of your data fits in memory it can still be fast. However if you plan on having much more data then disk you need to think about more RAM and OR SSD disks.
We do not use c* as an "in-memory store". However for many of our datasets we do not have a separate caching tier. In those cases cassandra is both our "database" and our "in-memory store" if you want to use those terms :)
On Wed, Mar 6, 2013 at 12:02 PM, Drew Kutcharian <email@example.com>
Thanks guys, this is what I was looking for.
@Edward. I definitely like crazy ideas ;), I think the only issue here is that C* is a disk space hug, so not sure if that would be feasible since free RAM is not as abundant as disk. BTW, I watched your presentation, are you guys still using C* as in-memory store?
Read at ONE.
READ_REPAIR_CHANCE as low as possible.
Use short TTL and short GC_GRACE.
Make the in memory memtable size as high as possible to avoid flushing and compacting.
Optionally turn off commit log.
You can use cassandra like memcache but it is not a memcache replacement. Cassandra persists writes and compacts SSTables, memcache only has to keep data in memory.
If you want to try a crazy idea. try putting your persistent data on a ram disk! Not data/system however!
On Wed, Mar 6, 2013 at 2:45 AM, aaron morton <firstname.lastname@example.org>
consider disabling durable_writes in the KS config to remove writing to the commit log. That will speed things up for you. Note that you risk losing data is cassandra crashes or is not shut down with nodetool drain.
Even if you set the gc_grace to 0, deletes will still need to be committed to disk.
Freelance Cassandra Developer
Thanks Ben, that article was actually the reason I started thinking about removing memcached.
I wanted to see what would be the optimum config to use C* as an in-memory store.
Check out http://techblog.netflix.com/2012/07/benchmarking-high-performance-io-with.html
Netflix used Cassandra with SSDs and were able to drop their memcache layer. Mind you they were not using it purely as an in memory KV store.
I'm thinking about using Cassandra as an in-memory key/value store instead of memcached for a new project (just to get rid of a dependency if possible). I was thinking about setting the replication factor to 1, enabling off-heap row-cache and setting gc_grace_period to zero for the CF that will be used for the key/value store.
Has anyone tried this? Any comments?