[ https://issues.apache.org/jira/browse/CASSANDRA-1041?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12863598#action_12863598 ]
Stu Hood commented on CASSANDRA-1041: ------------------------------------- An alternate solution has been raised before: partitioning the data stored on disk into multiple ranges. For example, when a major compaction reaches a size threshold (as configured here), it creates N output SSTables (rather than 1) covering disjoint key ranges, and records the range that each SSTable is responsible for. With N == 2 for instance, you'd have two sets of SSTables that could be major-compacted individually. > Skip large size (Configurable) SSTable in minor or/and major compaction > ----------------------------------------------------------------------- > > Key: CASSANDRA-1041 > URL: https://issues.apache.org/jira/browse/CASSANDRA-1041 > Project: Cassandra > Issue Type: New Feature > Components: Core > Reporter: Schubert Zhang > Priority: Minor > Attachments: CASSANDRA-1041-0.6.1.patch, CASSANDRA-1041-0.6.patch > > > When the SSTable files are large enough, such as 100GB, the compaction > (include minor and major) cost is big (disk IO, CPU, memory), etc. > In some applications, we accept not compcating all SSTables to the final very > large ones. > This feature provide two optional configurable attributes > MinorCompactSkipInGB and MajorCompactSkipInGB for each ColumnFamily. > The optional MinorCompactSkipInGB attribute specifies the maximum size of > SSTables which will be compcated in minor-compaction. The SSTables larger > than MinorCompactSkipInGB will be skipped. The optional MajorCompactSkipInGB > attribute is same for major-compaction. > The default of these attributes are 0, means do not skip, just as current > 0.6.1. -- This message is automatically generated by JIRA. - You can reply to this email to add a comment to the issue online.