Cassandra删除与墓碑的清理策略

Cassandra 中的删除操作

在 Cassandra 数据库中，删除操作是一个相对复杂的过程，与传统关系型数据库有所不同。当执行删除操作时，Cassandra 不会立即从磁盘上移除数据，而是采用一种称为“墓碑”（Tombstone）的机制来标记要删除的数据。这种机制对于 Cassandra 的高可用性和一致性模型至关重要。

删除行

假设我们有一个简单的用户表，用于存储用户信息，表结构如下：

CREATE TABLE users (
    user_id UUID PRIMARY KEY,
    username TEXT,
    email TEXT
);

要删除一个用户，例如 user_id 为 123e4567-e89b-12d3-a456-426614174000 的用户，可以使用以下 CQL 语句：

DELETE FROM users WHERE user_id = 123e4567-e89b-12d3-a456-426614174000;

执行此删除操作后，Cassandra 不会立即将该行数据从磁盘上删除。相反，它会在数据所在的 SSTable（Sorted String Table，Cassandra 存储数据的核心文件格式）中放置一个墓碑标记。这个墓碑标记记录了删除操作的时间戳等信息。

删除列

如果只想删除用户的 email 列，可以使用以下语句：

DELETE email FROM users WHERE user_id = 123e4567-e89b-12d3-a456-426614174000;

同样，Cassandra 会为该列放置一个墓碑标记，而不是立即删除该列的数据。

墓碑的概念

墓碑在 Cassandra 中扮演着关键角色，它是一种特殊的元数据，用于标记已删除的数据。墓碑包含了删除操作的时间戳、删除操作的发起者等信息。

墓碑的作用

一致性维护：在 Cassandra 的分布式环境中，多个副本可能存在于不同的节点上。当执行删除操作时，所有副本节点都需要收到删除信息。墓碑确保了即使某些副本节点暂时不可用，后续恢复时也能正确应用删除操作，从而维护数据的一致性。
防止数据误恢复：由于 Cassandra 采用最终一致性模型，数据可能会在不同节点上存在不同版本。墓碑标记了已删除的数据，防止旧版本的数据在某些情况下被错误地恢复。

墓碑的存储

墓碑信息存储在 SSTable 中与实际数据相同的位置。每个墓碑都有一个对应的时间戳，称为“删除时间戳”（Deletion Timestamp）。这个时间戳用于确定墓碑的有效性和在一致性检查时的优先级。

墓碑的清理策略

Cassandra 采用了多种策略来清理墓碑，以避免墓碑占用过多的存储空间和影响查询性能。

墓碑的 TTL（Time - To - Live）

每个墓碑都有一个默认的 TTL，默认为 10 天（可通过配置文件 cassandra.yaml 中的 gc_grace_seconds 参数进行修改）。在 TTL 过期之前，墓碑会一直存在，标记数据为已删除状态。当 TTL 过期后，墓碑所标记的数据就可以被安全地清理。

例如，如果我们修改 gc_grace_seconds 为 86400（即 1 天），在 cassandra.yaml 文件中添加或修改以下配置：

gc_grace_seconds: 86400

然后重启 Cassandra 服务使配置生效。这意味着删除操作后的墓碑在 1 天后就可以被清理。

压缩（Compaction）与墓碑清理

Cassandra 的压缩机制在墓碑清理过程中起着重要作用。当执行压缩操作时，多个 SSTable 会被合并成一个新的 SSTable。在合并过程中，过期的墓碑所标记的数据不会被复制到新的 SSTable 中，从而实现了墓碑的清理。

大小分层压缩（Size - Tiered Compaction Strategy，STCS）：这是 Cassandra 默认的压缩策略。在 STCS 中，SSTable 会根据大小被分为不同的层级。当一个层级中的 SSTable 数量达到一定阈值时，就会触发压缩操作。在压缩过程中，过期墓碑所标记的数据会被丢弃。
分层时间戳压缩（Leveled Compaction Strategy，LCS）：LCS 也是一种常用的压缩策略。它将 SSTable 按照层级组织，不同层级的 SSTable 包含不同时间范围的数据。在压缩过程中，同样会清理过期的墓碑。

手动清理墓碑

在某些特殊情况下，可能需要手动清理墓碑。可以使用 nodetool repair 命令来强制修复节点之间的数据一致性，并清理过期的墓碑。例如，要对节点 192.168.1.100 执行修复操作，可以运行以下命令：

nodetool -h 192.168.1.100 repair

nodetool repair 会遍历节点上的所有数据，并与其他副本节点进行比较和同步。在这个过程中，过期的墓碑会被清理。

墓碑对性能的影响

虽然墓碑机制保证了 Cassandra 的一致性和高可用性，但它也会对性能产生一定的影响。

存储开销

墓碑会占用额外的存储空间。随着删除操作的不断进行，墓碑的数量可能会逐渐增多，导致存储开销增大。特别是在高写入和高删除的场景下，墓碑占用的空间可能会成为一个问题。

查询性能

当执行查询操作时，Cassandra 需要检查数据是否被墓碑标记。如果存在大量墓碑，查询过程中的额外检查会增加查询的延迟。此外，在压缩操作期间，由于需要处理墓碑，也可能会影响系统的整体性能。

代码示例

为了更直观地理解 Cassandra 中的删除操作和墓碑清理，我们可以使用 Cassandra 的 Java 驱动来编写一些示例代码。

首先，确保已经在项目中添加了 Cassandra Java 驱动的依赖。如果使用 Maven，可以在 pom.xml 文件中添加以下依赖：

<dependency>
    <groupId>com.datastax.oss</groupId>
    <artifactId>java - driver - core</artifactId>
    <version>4.13.0</version>
</dependency>

以下是一个简单的 Java 示例，演示如何执行删除操作并观察墓碑的情况：

import com.datastax.oss.driver.api.core.CqlSession;
import com.datastax.oss.driver.api.core.cql.ResultSet;
import com.datastax.oss.driver.api.core.cql.SimpleStatement;

public class CassandraDeleteExample {
    public static void main(String[] args) {
        // 创建 Cassandra 会话
        try (CqlSession session = CqlSession.builder()
               .addContactPoint("127.0.0.1")
               .withLocalDatacenter("datacenter1")
               .build()) {

            // 创建示例表
            String createTableQuery = "CREATE TABLE IF NOT EXISTS example_table (" +
                    "id UUID PRIMARY KEY," +
                    "name TEXT" +
                    ")";
            session.execute(SimpleStatement.of(createTableQuery));

            // 插入数据
            String insertQuery = "INSERT INTO example_table (id, name) VALUES (uuid(), 'example_name')";
            session.execute(SimpleStatement.of(insertQuery));

            // 查询插入的数据
            String selectQuery = "SELECT * FROM example_table";
            ResultSet resultSet = session.execute(SimpleStatement.of(selectQuery));
            resultSet.forEach(row -> System.out.println("Inserted data: " + row));

            // 删除数据
            String deleteQuery = "DELETE FROM example_table WHERE id = " + resultSet.one().getUuid("id");
            session.execute(SimpleStatement.of(deleteQuery));

            // 查询已删除的数据（应该为空）
            resultSet = session.execute(SimpleStatement.of(selectQuery));
            if (resultSet.isEmpty()) {
                System.out.println("Data has been deleted.");
            }

            // 等待一段时间（模拟墓碑存在期间）
            try {
                Thread.sleep(10000);
            } catch (InterruptedException e) {
                e.printStackTrace();
            }

            // 手动执行修复操作清理墓碑（在实际生产中应谨慎使用）
            // 这里只是示例，实际操作需要通过 nodetool 命令在服务器端执行
            // session.execute(SimpleStatement.of("nodetool repair"));

            // 再次查询已删除的数据（如果墓碑已清理，数据不应再出现）
            resultSet = session.execute(SimpleStatement.of(selectQuery));
            if (resultSet.isEmpty()) {
                System.out.println("Data is still not present after potential tombstone cleanup.");
            }
        }
    }
}

在这个示例中，我们首先创建了一个示例表并插入了一条数据。然后执行删除操作，并观察到数据已被删除。之后，我们模拟了墓碑存在的一段时间，并理论上可以通过手动执行 nodetool repair 命令（在实际代码中通过服务器端执行）来清理墓碑，最后再次查询以确认数据是否因为墓碑清理而不会再次出现。

总结与最佳实践

合理设置 TTL：根据业务需求合理设置 gc_grace_seconds 参数，确保墓碑不会在系统中停留过长时间，同时也要考虑到副本同步等因素，避免过早清理墓碑导致数据不一致。
监控墓碑数量：通过 Cassandra 的监控工具，如 JMX（Java Management Extensions）或 Prometheus + Grafana 等，监控墓碑的数量和增长趋势。如果发现墓碑数量异常增长，可能需要调整业务逻辑或压缩策略。
优化删除操作：尽量避免频繁的删除操作，特别是在高并发场景下。如果可能，可以采用逻辑删除的方式，通过在表中添加一个标记列来表示数据是否已删除，而不是执行物理删除操作，从而减少墓碑的产生。

通过深入理解 Cassandra 中删除操作和墓碑清理策略，并遵循最佳实践，可以有效地管理 Cassandra 数据库，提高系统的性能和稳定性。在实际应用中，还需要根据具体的业务场景和数据量进行适当的调整和优化。