The only current solution is to truncate it periodically. I opened https://issues.apache.org/jira/browse/CASSANDRA-12701 about it if interested in following
On Wed, Oct 5, 2016 at 4:23 PM, Saladi Naidu <naidusp2...@yahoo.com> wrote: > We are seeing following warnings in system.log, As > *compaction_large_partition_warning_threshold_mb* in cassandra.yaml file > is as default value 100, we are seeing these warnings > > 110:WARN [CompactionExecutor:91798] 2016-10-05 00:54:05,554 > BigTableWriter.java:184 - Writing large partition > system_distributed/repair_history:gccatmer:mer_admin_job > (115943239 bytes) > > 111:WARN [CompactionExecutor:91798] 2016-10-05 00:54:13,303 > BigTableWriter.java:184 - Writing large partition > system_distributed/repair_history:gcconfigsrvcks:user_activation (163926097 > bytes) > > > When I looked at the table definition it is partitioned by keyspace and > cloumnfamily, under this partition, repair history is maintained. When I > looked at the count of rows in this partition, most of the paritions have > >200,000 rows and these will keep growing because of the partition strategy > right. There is no TTL on this so any idea what is the solution for reducing > partition size. > > > I also looked at size_estimates table for this column family and found that > the mean partition size for each range is 50,610,179 which is very large > compared to any other tables. > >
