[
https://issues.apache.org/jira/browse/CASSANDRA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921914#action_12921914
]
Peter Schuller commented on CASSANDRA-1608:
-------------------------------------------
With respect to tracking information, I meant tracking the information
necessary to make the determination as to which rows to supersede or otherwise
act upon, rather than keeping track of what *has* been superseded (which as you
point out is dealt with by bloom filters).
In the case of simple criteria (such as seeing a single read spread across more
than N sstables) no such tracking is necessary. But I am concerned with
strategies that imply having to keep significant amounts of data over time,
such as anything based on row-level frequency/recency of access.
In particular, if one hopes to supersede so effectively that hot rows
(regardless of sstable spread) end up in separate sstables with high locality
of access, will not this need such row-level information tracking?
> 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.
