cassandra-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jonathan Haddad <>
Subject Re: Effect of frequent mutations / memtable
Date Fri, 26 May 2017 15:00:02 GMT
If you have a small amount of hot data, enable the row cache. The memtable
is not designed to be a cache. You will not see a massive performance
impact of writing one to disk. Sstables will be in your page cache, meaning
you won't be hitting disk very often.
On Fri, May 26, 2017 at 7:41 AM Max C <> wrote:

> In my case, we're using Cassandra to store QA test data — so the pattern
> is that we may do a bunch of updates within a few minutes / hours, and then
> the data will essentially be read-only for the rest of its lifetime
> (years).  My question is the same — do we need to worry about the
> performance impact of having N mutations written to the SSTable — or will
> these mutations generally be constrained to the mem table?
> - Max
> > Hi,
> >
> > I am using a updates to a column with a ttl to represent a lock. The
> owning process keeps updating the lock's TTL as long as it is running. If
> the process crashes, the lock will timeout and be deleted. Then another
> process can take over.
> >
> > I have used this pattern very successfully over years with TTLs in the
> order of tens of seconds.
> >
> > Now I have a use case in mind that would require much smaller TTLs, e.g.
> 1 or two seconds and I am worried about the increased number of mutations
> and possible effect on SSTables.
> >
> > However: I'd assume these frequent updates on a cell to mostly happen in
> the memtable resulting in only occasional manifestation in SSTables.
> >
> > Is that assumption correct and if so, what config parameters should I
> tweak to keep the memtable from being flushed for longer periods of time?
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:

View raw message