[
https://issues.apache.org/jira/browse/CASSANDRA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921913#action_12921913
]
Stu Hood commented on CASSANDRA-1608:
-------------------------------------
> Regarding superseding rows in sstables; what would be the criteria for
> picking which rows to supersede for?
A configurable threshold on access count is one metric: you could attach an
access counter to rows in the memtable or rowcache. If a row reaches a
threshold of accesses, then you supersede it by storing the data for the read
in the memtable, and marking it superseded in any sstables.
(This works for skinny rows, but just like with the row cache, we need a
strategy for wider rows.)
Another metric would be the minimum number of sstables to supersede: if a row
is stored in 1 sstable, (obviously) don't supersede, but if it is stored in 4,
supersede, etc.
> would that require tracking some information over time at row level
> granularity? (I'm concerned about the overhead of such tracking.)
I don't think so? If something was recently superseded, it will be stored in 1
sstable, and there is no need to supersede it reaches your threshold.
> If so, an observation is that false positives are allowed for the stats
I think this is what we get from the bloom filter edits: sometimes a supersede
will fail for some sstables, but it's not really a big deal, since the whole
operation probably still pushes you below your threshold for sstables.
> Redesigned Compaction
> ---------------------
>
> Key: CASSANDRA-1608
> URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
> Project: Cassandra
> Issue Type: Improvement
> Components: Core
> Reporter: Chris Goffinet
> Fix For: 0.7.1
>
>
> After seeing the I/O issues in CASSANDRA-1470, I've been doing some more
> thinking on this subject that I wanted to lay out.
> I propose we redo the concept of how compaction works in Cassandra. At the
> moment, compaction is kicked off based on a write access pattern, not read
> access pattern. In most cases, you want the opposite. You want to be able to
> track how well each SSTable is performing in the system. If we were to keep
> statistics in-memory of each SSTable, prioritize them based on most accessed,
> and bloom filter hit/miss ratios, we could intelligently group sstables that
> are being read most often and schedule them for compaction. We could also
> schedule lower priority maintenance on SSTable's not often accessed.
> I also propose we limit the size of each SSTable to a fix sized, that gives
> us the ability to better utilize our bloom filters in a predictable manner.
> At the moment after a certain size, the bloom filters become less reliable.
> This would also allow us to group data most accessed. Currently the size of
> an SSTable can grow to a point where large portions of the data might not
> actually be accessed as often.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
