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 <mc_cassan...@core43.com> 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: user-unsubscr...@cassandra.apache.org > For additional commands, e-mail: user-h...@cassandra.apache.org > >
