If you're doing high volumes of writes that simply overwrite values, you're
going to see memtables flush to disk when the commit log hits it's space
limit and you recycle commit log segments.
I agree, it makes sense to not write these values to disk only to compact
them, if this is your pattern.
Jonathan,
On 26 May 2017, at 17:00, Jonathan Haddad wrote:
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
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 w
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 i
