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?