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*.
On Mar 6, 2013, at 9:08 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > 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 <d...@venarc.com> wrote: > 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? > > > > > On Mar 6, 2013, at 7:44 AM, Edward Capriolo <edlinuxg...@gmail.com> wrote: > >> http://www.slideshare.net/edwardcapriolo/cassandra-as-memcache >> >> 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 <aa...@thelastpickle.com> wrote: >> 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. >> >> Cheers >> >> ----------------- >> Aaron Morton >> Freelance Cassandra Developer >> New Zealand >> >> @aaronmorton >> http://www.thelastpickle.com >> >> On 5/03/2013, at 9:51 AM, Drew Kutcharian <d...@venarc.com> wrote: >> >>> 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. >>> >>> -- Drew >>> >>> >>> On Mar 5, 2013, at 2:39 AM, Ben Bromhead <b...@instaclustr.com> wrote: >>> >>>> 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. >>>> >>>> Ben >>>> Instaclustr | www.instaclustr.com | @instaclustr >>>> >>>> >>>> >>>> On 05/03/2013, at 4:33 PM, Drew Kutcharian <d...@venarc.com> wrote: >>>> >>>>> Hi Guys, >>>>> >>>>> 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? >>>>> >>>>> Thanks, >>>>> >>>>> Drew >>>>> >>>>> >>>> >>> >> >> > >
