Optimization Cassandra是否需要对完全不可变的数据进行自动压缩？

我试图优化生产中的Cassandra表的性能，该表是带有时间戳的经典事件数据。通过不同的设置，我花了一些时间研究了压缩策略和cassandra中的wat压缩

起初，我认为TimeWindowCompression非常适合我们的用例，但后来我意识到我们从不删除或更新数据

---

完全禁用压缩是否可能更好？在完全没有压缩策略的情况下，SSTables是如何形成的？

禁用压缩确实不是一个好选项，但您可以根据应用程序行为更改压缩策略。在您的情况下，您可以使用大小分层压缩策略或分层压缩策略

然而，TimeWindowCompactionStrategy是时间序列数据的一个很好的选择。 您可以参考以下详细信息以了解用例

TimeWindowCompactionStrategy（TWCS）是专为工作负载设计的，在工作负载中，按数据的时间戳对磁盘上的数据进行分组是有益的，这是工作负载本质上是时间序列或所有数据都是用TTL写入时的一个共同目标。在即将到期的/TTL工作负载中，整个SSTable的内容可能在大约相同的时间到期，从而允许完全删除它们。

---

当内存存储（memtables）已满或刷新时，会将表写入磁盘。如果禁用表上的压缩，最终将得到许多非常小的表。无论是要更新还是删除数据，都需要在写入数据时压缩数据

---

您使用的压缩策略将取决于您的访问需求。是选择压缩策略的一个很好的基本指南，也是cassandra中更详细的压缩指南。

如前所述，当发生写操作时，内存会在特定条件下刷新到磁盘。每次发生这种情况，您都会得到一个sstable。随着时间的推移，随着更改的继续，将有多个SSTABLE组成该节点上的表。假设一个表有多个sstables，则可能有一个“行”位于多个sstable中，当该行发生读取时，Cassandra必须读取该行的所有sstables，合并结果，然后响应。这会减慢读取速度。记住，卡桑德拉是高度优化的写，读付出的代价。正如您所提到的，压缩也用于墓碑/删除清理

您可以决定压缩是如何发生的。默认为大小分层压缩策略（STCS）。此策略的算法是，当X个sstables大小相似时，它们会被压缩到一个新的sstable中（旧的sstables会被丢弃）。如果新sstable的结果更大（例如，将4个sstable压缩为1，并且所有行都是唯一的），则可能需要很长时间才能再次参与压缩（因为需要X个相同大小的sstable才能满足要求）。这有意义吗

你的意思是“为什么不只拥有一张桌子呢？”。对于读取，单个“打包”的sstable是最佳选择。但是，随着时间的推移，随着更改的发生，您将有新的sstable（sstables将始终为新更改生成—您无法停止），并且您的一个大sstable（如前所述）可能无法清理，从而导致性能再次降低。那是STCS

还有其他策略——每种策略都针对特定条件进行了优化。这样做的目的是尽可能地保持事物的整洁，而不必不断地压缩数据来压倒系统——因此可以选择不同的方法/策略。每个人都对其他人有利也有弊

要记住的另一件事是读取发生在分区级别。如果您有一个表，其中分区键是主键，并且插入的每一行都没有删除、TTL或其他类似性质的内容，那么您是正确的，对于这种类型的表，根本不需要压缩。你可以有一百万张sstables，这没关系。但是，如果您的主键是分区键的一部分，而不是全部，则读取性能可能会受到影响（读取发生在分区级别，并且每个分区都有多行和SSTABLE）。在这种情况下，您可能不需要压缩来进行清理（同样假设只进行插入，不进行TTL/删除等），但是单个分区的sstables越多，读取速度可能越慢（取决于每个分区驻留的sstables数量，以及使用一些内置优化来过滤分区的sstables）

---

希望这能有所帮助。

谢谢您的回答！然而，我仍然不确定为什么我需要一个压缩策略。压缩除了删除墓碑和合并更新之外还能做些什么吗？将所有数据放在SS1表中是否有问题？如果不删除或更新，压缩仍然有许多好处，如系统元数据压缩、合并小型SS1表等。