cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Benjamin Coverston (JIRA)" <j...@apache.org>
Subject [jira] [Issue Comment Edited] (CASSANDRA-1608) Redesigned Compaction
Date Mon, 20 Jun 2011 23:32:48 GMT

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

Benjamin Coverston edited comment on CASSANDRA-1608 at 6/20/11 11:30 PM:
-------------------------------------------------------------------------

Attaching the latest version.

Levels are scored according to size rather than number of SSTables.

Performance kind of sucked until I made a few tweaks.

You can modify the LevelDB SSTable size by the following command (example) in the CLI:

update column family Standard1 with compaction_strategy_options=[{ sstable_size_in_mb : 10
}];


Using a flush size of 64MB and an sstable_size_in_mb of 5 worked pretty well for keeping compactions
moving through the levels and handling new SSTables as they entered the system.

I also enabled concurrent compactions which, to my surprise, helped considerably. In testing
I also removed compaction throttling, but in the end I don't think it mattered too much for
me.

This version also adds a manifest and recovery code to the mix. While running you can cat
the manifest, it's human readable, and quite beautiful to see the levels interact with each
other as SSTables are flushed and compactions roll through the levels.

Right now I'm getting an exception on startup from the keycache, I'm going to investigate
that, but I think it may have to do with the fact that I am initializing the compaction manager
_after_ the CFS.








      was (Author: bcoverston):
    Attaching the latest version.

Levels are scored according to size rather than number of SSTables.

Performance kind of sucked until I made a few tweaks.

You can modify the LevelDB SSTable size by the following command (example) in the CLI:

update column family Standard1 with compaction_strategy_options=[{ sstable_size_in_mb : 10
}];


Using a flush size of 64MB and an sstable_size_in_mb of 5 worked pretty well for keeping compactions
moving through the levels and handling new SSTables as they entered the system.

I also enabled concurrent compactions which, to my surprise, helped considerably. In testing
I also removed compaction throttling, but in the end I don't think it mattered too much for
me.

This version also adds a manifest and recovery code to the mix. While running you can cat
the manifest, it's human readable, and quite beautiful to see the levels interact with each
other as SSTables are flushed and compactions roll through the levels.

Right now I'm getting an exception on startup from the keycache, I'm going to investigate
that, but I think it may have to do with the fact that I am not initializing the compaction
manager _after_ the CFS.







  
> Redesigned Compaction
> ---------------------
>
>                 Key: CASSANDRA-1608
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1608
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Core
>            Reporter: Chris Goffinet
>         Attachments: 0001-leveldb-style-compaction.patch, 1608-v2.txt, 1608-v3.txt
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira

        

Mime
View raw message