cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Peter Schuller (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1608) Redesigned Compaction
Date Sun, 17 Oct 2010 21:07:24 GMT

    [ https://issues.apache.org/jira/browse/CASSANDRA-1608?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12921900#action_12921900
] 

Peter Schuller commented on CASSANDRA-1608:
-------------------------------------------

Regarding superseding rows in sstables; what would be the criteria for picking which rows
to supersede for? A simple threshold would be easy and certainly addresses extreme cases of
rows being spread. But if one also expects to take into account of often the rows are read,
that would imply recenticity or frequency tracking?

A simple threshold on sstable count would certainly help avoiding the extreme cases of reads
across many sstables. 

But in terms of trying to keep frequently accessed data together with high locality (as briefly
alluded to in CASSANDRA-1625), would that require tracking some information over time at row
level granularity? (I'm concerned about the overhead of such tracking.)

If so, an observation is that false positives are allowed for the stats. I.e., recenticity/frequency
could be associated with something like 64-bit-hash-of-key rather than keys, meaning that
some optimizations become possible (e.g. smacking hash-of-key:counter pairs into large byte
arrays).




> 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.


Mime
View raw message