使用 scylla db 的读/写密集型程序使用哪种压缩策略答案

【问题标题】：Which compaction strategy to use for both read/write intensive program using scylla db使用 scylla db 的读/写密集型程序使用哪种压缩策略
【发布时间】：2019-12-16 18:47:30
【问题描述】：

我有一个程序密集地读写（相同的读写量，对于写入，4/5 更新和 1/5 插入）。 SizedTired 压实比 Leveled 更好吗？

大多数数据的 TTL 为 7 天，其他数据为 1 天。在这种情况下，是首选时间窗口策略吗？

【问题讨论】：

标签： cassandra cql cqlsh scylla

【解决方案1】：

Timewindow 不适合，因为您的更新使其不太理想。 Sizetier 以更多的容量使用为代价表现最好。在此处查看压缩算法选择表： https://www.scylladb.com/webinar/on-demand-webinar-best-practices-for-data-modeling/

通常 STCS 是最好的默认设置

【讨论】：

【解决方案2】：

具有类似更新的 LeveledCompactionStrategy 是最好的选择，尤其是对于这样的混合读取。

【讨论】：

LCS 传统上对同时具有更新和 TTL 的工作负载存在问题：如果您的 tombstone 最终处于最后一个级别，那么工作负载的更新繁重性质将使大多数 SSTable 提升保持在较低级别，并且您可能永远无法使您的墓碑过期。同样对于 50% 的写入（无论是更新还是插入），LCS 可能会非常昂贵。
以防万一有人带着 Apache Cassandra（因为标记为 cassandra）来到这里 - Cassandra 的 LCS（和 TWCS）至少是特别是大量更新和 TTL（TWCS 更多时间序列和 ttl）。 STCS 是您提到的问题之一，即带有过时数据的 1tb sstables 没有得到压缩，因为几乎所有 sstables 中都存在更新的数据，因此读取非常昂贵。由于其他表中可能存在阴影，单个稳定的墓碑压缩有时无法清除最后一级的 ttl/墓碑。当然，Scylla 可能会有所不同，我听从专家的意见。