Cassandra表在两年内没有压缩？

Question

我具有下表的定义：

CREATE TABLE snap_websites.backend (
    key blob,
    column1 blob,
    value blob,
    PRIMARY KEY (key, column1)
) WITH COMPACT STORAGE
    AND CLUSTERING ORDER BY (column1 ASC)
    AND bloom_filter_fp_chance = 0.100000001
    AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
    AND comment = 'backend'
    AND compaction = {'class': 'org.apache.cassandra.db.compaction.DateTieredCompactionStrategy', 'max_threshold': '10', 'min_threshold': '4', 'tombstone_threshold': '0.02'}
    AND compression = {'enabled': 'false'}
    AND crc_check_chance = 1.0
    AND dclocal_read_repair_chance = 0.1
    AND default_time_to_live = 0
    AND gc_grace_seconds = 3600
    AND max_index_interval = 2048
    AND memtable_flush_period_in_ms = 3600000
    AND min_index_interval = 128
    AND read_repair_chance = 0.0
    AND speculative_retry = '99PERCENTILE';

[查看compaction设置，似乎应该不时压缩它...但是，大约2年后，该表在SELECT上的运行速度确实很慢，我可以在相应的数据中看到12,281个文件夹！我只检查了节点，我想所有节点都有类似的文件堆。

为什么会这样？可能是因为我从来没有给Cassandra休息一下，因此从未真正有时间进行压缩吗？ （即，我几乎总是在该表上运行某些进程，但是我没想到事情会变得如此糟糕！哇！）

命令行运行良好：

nodetools compact snapwebsites backend

并且文件的数量一直下降到9（毕竟，我现在该表中只有2行数据！）]

我真正需要知道的是：是什么阻止了Cassandra运行压缩过程？

Answer 1

我对DTCS不太记得，但是如果可以的话，我会考虑使用TWCS来代替它。它适用于时间序列数据（提到不久的将来，TDCS将会消失）。

-吉姆