压缩概述

Cassandra 中的数据是在 内存表 中创建的。一旦达到内存阈值，为了再次释放内存，数据将被写入 SSTable，这是一个驻留在磁盘上的 不可变 文件。

由于 SSTable 是不可变的，当数据被更新或删除时，旧数据不会被插入或更新覆盖，也不会从 SSTable 中删除。相反，将创建一个包含更新数据的具有新时间戳的新 SSTable，并将旧 SSTable 标记为删除。已删除数据的片段被称为 墓碑。

随着时间的推移，Cassandra 可能会在不同的 SSTable 中写入一个行的多个版本。每个版本可能包含一组具有不同时间戳的唯一存储的列。随着 SSTable 的累积，数据的分布可能需要访问越来越多的 SSTable 来检索完整的行。

为了保持数据库的健康，Cassandra 定期合并 SSTable 并丢弃旧数据。此过程称为 压缩。

由于在读取操作期间会查询 SSTable，因此保持 SSTable 的数量较少非常重要。写入操作会导致 SSTable 的数量增加，因此压缩是必要的。除了墓碑问题外，数据还会因其他原因被删除，例如某些数据的生存时间 (TTL) 到期。删除、更新或过期数据都是触发压缩的有效原因。

压缩实现的两个重要因素是性能提升和磁盘空间回收。如果 SSTable 包含必须读取的重复数据，则读取操作会变慢。一旦墓碑和重复数据被删除，读取操作就会更快。SSTable 使用磁盘空间，通过压缩减少 SSTable 的大小可以释放磁盘空间。

压缩在 SSTable 集合上进行。从这些 SSTable 中，压缩收集每个唯一行的所有版本，并使用每个行的列的最新版本（按时间戳）组装一个完整的行。合并过程是高效的，因为行在每个 SSTable 中按分区键排序，并且合并过程不使用随机 I/O。每个行的最新版本将写入一个新的 SSTable。旧版本以及任何准备删除的行将保留在旧 SSTable 中，并在完成挂起的读取后立即删除。

压缩的概念用于 Cassandra 中的不同类型的操作，这些操作的共同点是它们接受一个或多个 SSTable，进行合并，并输出新的 SSTable。压缩类型包括

不同的压缩策略可用于针对不同的工作负载进行优化。为您的工作负载选择正确的压缩策略将确保查询和压缩本身的最佳性能。

Cassandra 中的数据可以具有一个名为生存时间的附加属性 - 此属性用于在达到时间后自动删除已过期的数据。一旦 TTL 过期，数据就会被转换为墓碑，墓碑至少会保留 gc_grace_seconds 时间。请注意，如果您将 TTL 数据与没有 TTL 的数据（或 TTL 长度不同的数据）混合使用，Cassandra 将难以删除创建的墓碑，因为分区可能跨越多个 SSTable，并且不会同时压缩所有 SSTable。

如果 SSTable 只包含墓碑，并且可以保证该 SSTable 没有覆盖任何其他 SSTable 中的数据，则压缩操作可以删除该 SSTable。如果您看到只包含墓碑的 SSTable（请注意，一旦生存时间过期，TTL 数据就被视为墓碑），但它没有被压缩操作删除，则可能是其他 SSTable 包含更旧的数据。有一个名为 sstableexpiredblockers 的工具可以列出哪些 SSTable 可删除，以及哪些 SSTable 阻止它们被删除。使用 TimeWindowCompactionStrategy，可以通过启用 unsafe_aggressive_sstable_expiration 来删除保证（不检查是否有覆盖数据）。

使用增量修复，Cassandra 必须跟踪哪些数据已修复，哪些数据未修复。使用反压缩，已修复的数据被拆分为已修复和未修复的 SSTable。为了避免再次混合数据，对这两组数据分别运行单独的压缩策略实例，每个实例只知道已修复或未修复的 SSTable。这意味着，如果您只运行一次增量修复，然后不再运行，则已修复的 SSTable 中可能存在非常旧的数据，这些数据会阻止压缩操作删除未修复的（可能更新的）SSTable 中的墓碑。

由于墓碑和数据可能存在于不同的 SSTable 中，因此重要的是要意识到，丢失 SSTable 可能会导致数据再次变为活动状态 - 丢失 SSTable 的最常见方式是硬盘驱动器发生故障。为了避免使数据变为活动状态，墓碑和实际数据始终位于同一个数据目录中。这样，如果磁盘丢失，则分区的全部版本都会丢失，并且不会有任何数据被取消删除。为了实现这一点，除了包含已修复/未修复数据的压缩策略实例之外，还会为每个数据目录运行一个压缩策略实例，这意味着，如果您有 4 个数据目录，则将运行 8 个压缩策略实例。这除了避免数据被取消删除之外，还有其他一些好处

当写入 SSTable 时，会创建一个包含墓碑过期时间的直方图，并使用它来尝试查找包含大量墓碑的 SSTable，并在该 SSTable 上运行单个 SSTable 压缩，以期能够删除该 SSTable 中的墓碑。在开始此操作之前，还会检查删除任何墓碑的可能性以及该 SSTable 与其他 SSTable 的重叠程度。为了避免大多数这些检查，可以启用压缩选项 unchecked_tombstone_compaction。

所有压缩策略都有许多常见选项；

此外，请参阅每个策略部分以了解特定附加选项。

nodetool <nodetool> 实用程序提供了许多与合并相关的命令

可以使用 JMX 在单个节点上切换合并策略及其选项，这是一种在不影响整个集群的情况下试验设置的好方法。mbean 是

要更改的属性是CompactionParameters 或CompactionParametersJson（如果您使用的是 jconsole 或 jmc）。例如，json 版本的语法与您在ALTER TABLE <alter-table-statement> 语句中使用的语法相同

该设置将一直保留，直到有人执行影响合并设置的ALTER TABLE <alter-table-statement> 或重新启动节点。

使用合并选项log_all 启用，将在您的日志目录中生成更详细的合并日志文件。