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