已设置SSTABLE_SIZE_IN_MB为2048，为何仍生成12G SSTable？如何限制？

你的核心问题在于单个分区过大，导致设置的sstable_size_in_mb参数无法生效。Cassandra不允许将单个拆分到多个SSTable中，因此如果某个分区的大小超过2048MB，生成的SSTable就会和该分区大小一致（甚至多个大分区合并后更大）。从日志可见，已有单个分区达到4.441GiB，直接导致SSTable远超目标大小。

1. 定位大分区 #

先通过命令排查表的分区大小分布，明确问题分区：

nodetool tablehistograms msaiotsensingplatform ts_kv_cf

该命令会输出分区大小的百分位数，你可以找到最大分区对应的entity_type、entity_id、key和partition值，确认是分区键粒度太粗导致的数据堆积。

2. 细化分区键粒度（根本解决方案） #

你的表主键为((entity_type, entity_id, key, partition), ts)，其中partition字段是引发大分区的关键。如果当前partition是按天或更大时间粒度划分的，需将其拆分为更细的粒度（如按小时、15分钟）：

• 例如，若原partition是当天起始时间戳，可修改为按小时计算：partition = ts / 3600000（将时间戳转换为小时级数值）。
• 由于Cassandra不支持直接修改主键，需按以下步骤操作：
  1. 创建新表，使用细化后的分区键：

     CREATE TABLE ts_kv_cf_new (
         entity_type text,
         entity_id timeuuid,
         key text,
         partition bigint,
         ts bigint,
         bool_v boolean,
         dbl_v double,
         json_v text,
         long_v bigint,
         str_v text,
         PRIMARY KEY ((entity_type, entity_id, key, partition), ts)
     ) WITH CLUSTERING ORDER BY (ts ASC)
         AND additional_write_policy = '99p'
         AND bloom_filter_fp_chance = 0.01
         AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
         AND cdc = false
         AND compaction = {'class': 'LeveledCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4','sstable_size_in_mb': 2048}
         AND compression = {'chunk_length_in_kb': '16', 'class': 'LZ4Compressor'}
         AND crc_check_chance = 1.0
         AND default_time_to_live = 0
         AND extensions = {}
         AND gc_grace_seconds = 60
         AND max_index_interval = 2048
         AND memtable_flush_period_in_ms = 0
         AND min_index_interval = 128 
         AND read_repair = 'BLOCKING'
         AND speculative_retry = '99p';
     

  2. 迁移旧表数据到新表：小数据量用COPY命令，大数据量推荐使用Spark或DataStax Bulk Loader工具。
  3. 验证新表分区大小符合预期后，替换旧表。

3. 临时缓解方案（不推荐长期使用） #

若暂时无法修改表结构，可尝试以下操作，但无法解决根本问题：

• 增大sstable_size_in_mb值以匹配当前大分区大小，但会加剧读取、压缩的性能问题。
• 改用SizeTieredCompactionStrategy，该策略会合并大小相近的SSTable，但仍无法拆分大分区。

注意：Cassandra官方推荐单个分区大小不超过100MB，超阈值会引发压缩耗时久、读取延迟高、内存占用过大等问题，因此细化分区键粒度是唯一长期可行的解决方案。

内容的提问来源于stack exchange，提问作者huihui luo