【原文链接】About Deletes and Tombstones in Cassandra

从Apache Cassandra这样的系统中删除分布式和复制式的数据，要比在关系型数据库中删除数据要棘手得多。当我们考虑到Cassandra将其数据存储在磁盘上的不可改变的文件中时，删除的过程就变得更加有趣。在这样的系统中，为了记录发生了删除的事实，需要写入一个叫做 "墓碑"（tombstone）的特殊值，用于标识之前的值已经被删除。尽管这可能看起来很不寻常甚至有悖直觉（特别是当你意识到删除实际上会占用磁盘空间时），我们将用这篇博文来解释实际发生的事情，同时附上例子，你可以自行试验加深理解。

Cassandra：可用性 + 一致性

在我们深入了解细节之前，我们应该先退后一步进行回顾，看看Cassandra作为一个分布式系统是如何工作的，尤其是在可用性和一致性的背景下。这对于正确理解分布式删除以及其对应的潜在问题将会有所帮助。

可用性。为了确保可用性，Cassandra会复制数据。具体来说，根据复制因子（RF），每个数据的多个副本存储在不同的节点上。RF定义了每个数据中心每个 keyspace 要保存的副本数量。根据配置，每个副本也可以由不同的机架保存，只要有足够的机架可用，并且配置对应 snitch 和 topology 策略。采用这样的方法，当任何节点或机架发生故障时，仍然可以从其他副本中读取数据。

一致性。为了确保读取的数据具有很强的一致性，我们必须遵守以下规则。

CL.READ  = 用于读取的一致性级别（CL）。基本上是指Cassandra认为读取成功而必须确认的节点数量。
CL.WRITE = 用于写入的一致性级别（CL）
RF       = 复制因子

CL.READ + CL.WRITE > RF

这样我们就可以确保从至少一个写入数据的节点中读取。

用例：让我们考虑以下常见的配置

RF       = 3
CL.READ  = QUORUM = RF/2 + 1 = 2
CL.WRITE = QUORUM = RF/2 + 1 = 2

CL.READ + CL.WRITE > RF --> 4 > 3

通过这个配置，避免了单点故障（SPOF），从而收获了高可用性。我们可以承受损失一个节点，因为我们确信任何读取请求都会至少在一个节点上获取写入的数据，然后应用 Last Write Wins (LWW) 算法来选择哪个节点持有这次读的正确数据。
在这里插入图片描述理解了上述配置和行为，下面来看一些执行删除的例子。

分布式删除的问题

从上一节的内容了解到这种配置之下应该是强一致的。让我们暂时忘掉墓碑（tombstone），考虑一下 Cassandra 没有使用墓碑删除数据的情况。让我们考虑一个成功的删除，在一个节点上失败了（三个节点中，RF=3）。这个删除仍然会被认为是成功的（两个节点承认了删除，使用CL.QUORUM）。涉及该节点的下一次读取将是一个模棱两可的读取，因为没有办法确定什么是正确的：返回一个空响应还是返回数据？Cassandra一定会认为返回数据是正确的做法，所以删除经常会导致数据重新出现，被称为 "僵尸 "或 "幽灵"，它们的行为将是不可预测的。
在这里插入图片描述
注意：这个问题即使通过墓碑（tombstone）的方式也并没有完全解决，而是按照以下方式解决：作为 Cassandra 操作者，我们必须对任何执行删除的集群至少每 gc_grace_seconds 运行一次全面修复。参见下面的 "墓碑删除 "部分。

从 Cassandra 单节点的角度看删除问题

如前所述，墓碑解决了使用不可变文件（sstable）存储数据的系统中删除数据的问题。

Cassandra 的特点之一是它使用了一个日志结构的合并树（LSM树），而大多数 RDBMS 使用的是 B 树。理解这一点的最好方法是记住 Cassandra 总是将写的数据追加更新，读的时候负责将一行的数据碎片合并在一起，挑选每个列的最新版本返回。

LSM树的另一个属性是数据写在不可变的文件中（在Cassandra中称为SSTables）。正如最初讨论的那样，那么很明显，通过这样的系统，删除只能通过一种特殊的写来完成。读取将获取墓碑，而不考虑墓碑时间戳之前的任何数据。

墓碑

在Cassandra的上下文中，墓碑是与标准数据一起存储的特定数据。删除只不过是插入一个墓碑。当Cassandra读取数据时，它将从 memtable 和SSTables 中合并所有请求行的碎片。然后，它应用 Last Write Wins（LWW）算法来选择什么是正确的数据，不管它是标准值还是墓碑。

举个例子。

让我们考虑以下例子，在一个有3个节点的Cassandra 3.7集群上（使用CCM）。

CREATE KEYSPACE tlp_lab WITH replication = {'class': 'NetworkTopologyStrategy', 'datacenter1' : 3};
CREATE TABLE tlp_lab.tombstones (fruit text, date text, crates set<int>, PRIMARY KEY (fruit, date));

并添加一些数据

INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES ('apple', '20160616', {1,2,3,4,5});
INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES ('apple', '20160617', {1,2,3});
INSERT INTO tlp_lab.tombstones (fruit, date, crates) VALUES ('pickles', '20160616', {6,7,8}) USING TTL 2592000;

这是刚才存储的数据。

alain$ echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

fruit   | date     | crates
---------+----------+-----------------
apple | 20160616 | {1, 2, 3, 4, 5}
apple | 20160617 |       {1, 2, 3}
pickles | 20160616 |       {6, 7, 8}

现在我们需要手动刷新数据（即在磁盘上写一个新的SSTable，释放内存），因为内存不像磁盘上的SSTable，其内容是支持变更的，所以内存中的墓碑，更准确的说是memtable中的墓碑，会覆盖memtable中现有的任何值，这一行为与应用到磁盘的 sstable 上时存在区别。

nodetool -p 7100 flush

我们现在可以看到磁盘上的数据。

alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 72
drwxr-xr-x  11 alain  staff   374 Jun 16 20:53 .
drwxr-xr-x   3 alain  staff   102 Jun 16 20:25 ..
drwxr-xr-x   2 alain  staff    68 Jun 16 17:05 backups
-rw-r--r--   1 alain  staff    43 Jun 16 20:53 mb-5-big-CompressionInfo.db
-rw-r--r--   1 alain  staff   127 Jun 16 20:53 mb-5-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 16 20:53 mb-5-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 16 20:53 mb-5-big-Filter.db
-rw-r--r--   1 alain  staff    20 Jun 16 20:53 mb-5-big-Index.db
-rw-r--r--   1 alain  staff  4740 Jun 16 20:53 mb-5-big-Statistics.db
-rw-r--r--   1 alain  staff    61 Jun 16 20:53 mb-5-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 16 20:53 mb-5-big-TOC.txt

我们可以使用SSTabledump工具将 sstable 中的内容以可读的方式呈现

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-5-big-Data.db
[
  {
    "partition" : {
      "key" : [ "apple" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 19,
        "clustering" : [ "20160616" ],
        "liveness_info" : { "tstamp" : "2016-06-16T18:52:41.900451Z" },
        "cells" : [
          { "name" : "crates", "deletion_info" : { "marked_deleted" : "2016-06-16T18:52:41.900450Z", "local_delete_time" : "2016-06-16T18:52:41Z" } },
          { "name" : "crates", "path" : [ "1" ], "value" : "" },
          { "name" : "crates", "path" : [ "2" ], "value" : "" },
          { "name" : "crates", "path" : [ "3" ], "value" : "" },
          { "name" : "crates", "path" : [ "4" ], "value" : "" },
          { "name" : "crates", "path" : [ "5" ], "value" : "" }
        ]
      },
      {
        "type" : "row",
        "position" : 66,
        "clustering" : [ "20160617" ],
        "liveness_info" : { "tstamp" : "2016-06-16T18:52:41.902093Z" },
        "cells" : [
          { "name" : "crates", "deletion_info" : { "marked_deleted" : "2016-06-16T18:52:41.902092Z", "local_delete_time" : "2016-06-16T18:52:41Z" } },
          { "name" : "crates", "path" : [ "1" ], "value" : "" },
          { "name" : "crates", "path" : [ "2" ], "value" : "" },
          { "name" : "crates", "path" : [ "3" ], "value" : "" }
        ]
      }
    ]
  },
  {
    "partition" : {
      "key" : [ "pickles" ],
      "position" : 104
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 125,
        "clustering" : [ "20160616" ],
        "liveness_info" : { "tstamp" : "2016-06-16T18:52:41.903751Z", "ttl" : 2592000, "expires_at" : "2016-07-16T18:52:41Z", "expired" : false },
        "cells" : [
          { "name" : "crates", "deletion_info" : { "marked_deleted" : "2016-06-16T18:52:41.903750Z", "local_delete_time" : "2016-06-16T18:52:41Z" } },
          { "name" : "crates", "path" : [ "6" ], "value" : "" },
          { "name" : "crates", "path" : [ "7" ], "value" : "" },
          { "name" : "crates", "path" : [ "8" ], "value" : "" }
        ]
      }
    ]
  }
]

现在磁盘上存储了两个分区（3行，2行共享同一个分区）。现在让我们考虑不同类型的删除。

Cell 删除

在Cassandra存储引擎中，来自特定行的一列称为 "Cell"。

从行中删除一个单元格

DELETE crates FROM tlp_lab.tombstones WHERE fruit='apple' AND date ='20160617';

在对应的行中，crates 列显示为 null。

alain$ echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

fruit   | date     | crates
---------+----------+-----------------
apple | 20160616 | {1, 2, 3, 4, 5}
apple | 20160617 |            null
pickles | 20160616 |       {6, 7, 8}

(3 rows)

刷新后我们在磁盘上多了一个SSTable，mb-6-big。

alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 144
drwxr-xr-x  19 alain  staff   646 Jun 16 21:12 .
drwxr-xr-x   3 alain  staff   102 Jun 16 20:25 ..
drwxr-xr-x   2 alain  staff    68 Jun 16 17:05 backups
-rw-r--r--   1 alain  staff    43 Jun 16 20:53 mb-5-big-CompressionInfo.db
-rw-r--r--   1 alain  staff   127 Jun 16 20:53 mb-5-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 16 20:53 mb-5-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 16 20:53 mb-5-big-Filter.db
-rw-r--r--   1 alain  staff    20 Jun 16 20:53 mb-5-big-Index.db
-rw-r--r--   1 alain  staff  4740 Jun 16 20:53 mb-5-big-Statistics.db
-rw-r--r--   1 alain  staff    61 Jun 16 20:53 mb-5-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 16 20:53 mb-5-big-TOC.txt
-rw-r--r--   1 alain  staff    43 Jun 16 21:12 mb-6-big-CompressionInfo.db
-rw-r--r--   1 alain  staff    43 Jun 16 21:12 mb-6-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 16 21:12 mb-6-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 16 21:12 mb-6-big-Filter.db
-rw-r--r--   1 alain  staff     9 Jun 16 21:12 mb-6-big-Index.db
-rw-r--r--   1 alain  staff  4701 Jun 16 21:12 mb-6-big-Statistics.db
-rw-r--r--   1 alain  staff    59 Jun 16 21:12 mb-6-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 16 21:12 mb-6-big-TOC.txt

而这里是mb-6-big的内容。

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-6-big-Data.db
[
  {
    "partition" : {
      "key" : [ "apple" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 19,
        "clustering" : [ "20160617" ],
        "cells" : [
          { "name" : "crates", "deletion_info" : { "marked_deleted" : "2016-06-16T19:10:53.267240Z", "local_delete_time" : "2016-06-16T19:10:53Z" } }
        ]
      }
    ]
  }
]

看看这个墓碑删除的 cell 和插入的行 cell 相比有多相似。partition、row 和cell 都还在，只是在列的层面上没有liveness_info了。deletion_info 字段也相应地更新了。这就是一个 Cell 墓碑。

Row 删除

从分区中删除一条记录

DELETE FROM tlp_lab.tombstones WHERE fruit='apple' AND date ='20160617';

删除后，该行不再显示

alain$ echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

 fruit   | date     | crates
---------+----------+-----------------
   apple | 20160616 | {1, 2, 3, 4, 5}
 pickles | 20160616 |       {6, 7, 8}

(2 rows)

刷新后，磁盘上多了一个SSTable，'mb-7-big'，它的样子如下。

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-7-big-Data.db
[
  {
    "partition" : {
      "key" : [ "apple" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "row",
        "position" : 19,
        "clustering" : [ "20160617" ],
        "deletion_info" : { "marked_deleted" : "2016-06-16T19:31:41.142454Z", "local_delete_time" : "2016-06-16T19:31:41Z" },
        "cells" : [ ]
      }
    ]
  }
]

可以看到 cell 的值是一个空数组。row 墓碑是指没有liveness_info和没有cell的行。deletion_info 字段存在于行级别

Range 删除

从单个分区中删除一个范围（即许多行）。

DELETE FROM tlp_lab.tombstones WHERE fruit='apple' AND date > '20160615';

apple 分区不再返回数据，因为它已经没有行了。除非我们有比20160616小的数据

echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

fruit   | date     | crates
---------+----------+-----------
pickles | 20160616 | {6, 7, 8}

(1 rows)

刷新后，磁盘上多了一个SSTable，'mb-8-big'，内容如下。

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-8-big-Data.db
[
  {
    "partition" : {
      "key" : [ "apple" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "range_tombstone_bound",
        "start" : {
          "type" : "exclusive",
          "clustering" : [ "20160615" ],
          "deletion_info" : { "marked_deleted" : "2016-06-16T19:53:21.133300Z", "local_delete_time" : "2016-06-16T19:53:21Z" }
        }
      },
      {
        "type" : "range_tombstone_bound",
        "end" : {
          "type" : "inclusive",
          "deletion_info" : { "marked_deleted" : "2016-06-16T19:53:21.133300Z", "local_delete_time" : "2016-06-16T19:53:21Z" }
        }
      }
    ]
  }
]

我们可以看到，我们现在有一个新的特殊插入，它的类型字段 type 不是 row，而是range_tombstone_bound。并且伴随 start 和 end 字段：clustering key 从20160615排除到无穷大。那些带有range_tombstone_bound类型的条目按照预期嵌套在 apple 对应的分区中。所以从磁盘空间的角度来看，删除整个范围是相当高效的，我们并不是每个单元格写一个信息，只是存储对应的删除边界。

Partition 删除

删除整个分区

DELETE FROM tlp_lab.tombstones WHERE fruit='pickles';

在删除后，分区和所有嵌套的行都不再显示，正如预期的那样。该表现在是空的。

alain$ echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

 fruit | date | crates
-------+------+--------

(0 rows)

刷新后磁盘上多了一个SSTable，mb-9-big，内容如下。

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-9-big-Data.db
[
  {
    "partition" : {
      "key" : [ "pickles" ],
      "position" : 0,
      "deletion_info" : { "marked_deleted" : "2016-06-17T09:38:52.550841Z", "local_delete_time" : "2016-06-17T09:38:52Z" }
    }
  }
]

所以，我们又插入了一个特定的标记。Partition 类型的墓碑是指插入的分区有deletion_info，没有行。

注意：当使用集合类型时，每次使用整个集合进行复制操作的时候，range墓碑都会由INSERT和UPDATE操作生成，而并非更新原有集合。插入一个新集合，而不是追加或只更新原集合中的元素，也会导致先插入一个 range 墓碑 + 插入集合的新值。这样隐藏式进行的DELETE操作，往往导致一些奇怪的问题。

仔细看一下第一个SSTabledump的输出，就在上面的数据插入之后，在任何删除之前，你会发现一个墓碑已经存在了。

"cells" : [
  { "name" : "crates", "deletion_info" : { "marked_deleted" : "2016-06-16T18:52:41.900450Z", "local_delete_time" : "2016-06-16T18:52:41Z" } },
  { "name" : "crates", "path" : [ "1" ], "value" : "" },
  { "name" : "crates", "path" : [ "2" ], "value" : "" },
  { "name" : "crates", "path" : [ "3" ], "value" : "" },
  { "name" : "crates", "path" : [ "4" ], "value" : "" },
  { "name" : "crates", "path" : [ "5" ], "value" : "" }
]

从邮件列表中，我发现James Ravn用 list 举例讨论了这个话题，但对所有的集合类型都适用，这里不再展开更多的细节，我只是想指出这一点，因为乍看之下比较意外，见：http://www.jsravn.com/2015/05/13/cassandra-tombstones-collections.html#lists。

墓碑可能产生的问题

好了，现在我们明白了为什么我们要使用墓碑，并且对墓碑的内容有了大致的了解，让我们看看墓碑可能引起的潜在问题，以及我们可以采取哪些措施来缓解这些问题。

第一件显而易见的事情是，我们不仅没有删除数据，而是存储了更多的数据。在某些时候，我们需要删除这些墓碑，以释放一些磁盘空间，并限制不必要的数据读取量，改善延迟和资源利用率。正如我们很快就会看到的那样，这是通过 Compaction 的过程来实现的。

Compactions

当我们读取一条特定的行时，需要查阅的SSTables越多，读取速度就越慢。因此，为了保持较低的读取延迟，有必要通过 Compaction 的过程来合并 sstable 文件。同时因为我们要继续尽可能地释放磁盘空间，所以这一过程也包含删除符合条件的墓碑。

Compaction 的工作方式是合并来自多个SSTables的行片段，在条件满足的情况下删除墓碑。这些条件部分是在创建表的时候指定的，从而可以调整，比如gc_grace_seconds，部分条件由于Cassandra内部实现的原因，是硬编码的，以确保数据的持久性和一致性。确保所有数据片段所在的 sstable 都参与当前的 compaction 中（通常被称为 "重叠SSTables"）是必要的，以避免不一致，因为一旦墓碑被驱逐，这些数据就会重新出现，形成这种 "僵尸 "数据。

考虑到上面的例子。在所有的删除和刷新之后，表文件夹的样子是这样的。

alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 360
drwxr-xr-x  43 alain  staff  1462 Jun 17 11:39 .
drwxr-xr-x   3 alain  staff   102 Jun 16 20:25 ..
drwxr-xr-x   2 alain  staff    68 Jun 16 17:05 backups
-rw-r--r--   1 alain  staff    43 Jun 17 11:13 mb-10-big-CompressionInfo.db
-rw-r--r--   1 alain  staff    43 Jun 17 11:13 mb-10-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 17 11:13 mb-10-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 11:13 mb-10-big-Filter.db
-rw-r--r--   1 alain  staff     9 Jun 17 11:13 mb-10-big-Index.db
-rw-r--r--   1 alain  staff  4701 Jun 17 11:13 mb-10-big-Statistics.db
-rw-r--r--   1 alain  staff    59 Jun 17 11:13 mb-10-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 11:13 mb-10-big-TOC.txt
-rw-r--r--   1 alain  staff    43 Jun 17 11:33 mb-11-big-CompressionInfo.db
-rw-r--r--   1 alain  staff    53 Jun 17 11:33 mb-11-big-Data.db
-rw-r--r--   1 alain  staff     9 Jun 17 11:33 mb-11-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 11:33 mb-11-big-Filter.db
-rw-r--r--   1 alain  staff     9 Jun 17 11:33 mb-11-big-Index.db
-rw-r--r--   1 alain  staff  4611 Jun 17 11:33 mb-11-big-Statistics.db
-rw-r--r--   1 alain  staff    59 Jun 17 11:33 mb-11-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 11:33 mb-11-big-TOC.txt
-rw-r--r--   1 alain  staff    43 Jun 17 11:33 mb-12-big-CompressionInfo.db
-rw-r--r--   1 alain  staff    42 Jun 17 11:33 mb-12-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 17 11:33 mb-12-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 11:33 mb-12-big-Filter.db
-rw-r--r--   1 alain  staff     9 Jun 17 11:33 mb-12-big-Index.db
-rw-r--r--   1 alain  staff  4611 Jun 17 11:33 mb-12-big-Statistics.db
-rw-r--r--   1 alain  staff    59 Jun 17 11:33 mb-12-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 11:33 mb-12-big-TOC.txt
-rw-r--r--   1 alain  staff    43 Jun 17 11:39 mb-13-big-CompressionInfo.db
-rw-r--r--   1 alain  staff    32 Jun 17 11:39 mb-13-big-Data.db
-rw-r--r--   1 alain  staff     9 Jun 17 11:39 mb-13-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 11:39 mb-13-big-Filter.db
-rw-r--r--   1 alain  staff    11 Jun 17 11:39 mb-13-big-Index.db
-rw-r--r--   1 alain  staff  4591 Jun 17 11:39 mb-13-big-Statistics.db
-rw-r--r--   1 alain  staff    65 Jun 17 11:39 mb-13-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 11:39 mb-13-big-TOC.txt
-rw-r--r--   1 alain  staff    43 Jun 17 11:12 mb-9-big-CompressionInfo.db
-rw-r--r--   1 alain  staff   127 Jun 17 11:12 mb-9-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 17 11:12 mb-9-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 11:12 mb-9-big-Filter.db
-rw-r--r--   1 alain  staff    20 Jun 17 11:12 mb-9-big-Index.db
-rw-r--r--   1 alain  staff  4740 Jun 17 11:12 mb-9-big-Statistics.db
-rw-r--r--   1 alain  staff    61 Jun 17 11:12 mb-9-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 11:12 mb-9-big-TOC.txt

你的SSTable很可能与上面的例子不一致，但是插入和删除的内容是完全一样的。我们可以看到这个表实际上是空的。存储在磁盘上的文件只包含墓碑和他们专门删除的条目。从读取的角度来看，没有任何结果返回。

echo "SELECT * FROM tlp_lab.tombstones LIMIT 100;" | cqlsh

fruit | date | crates
-------+------+--------

(0 rows)

此时，让我们触发一个 major compaction 来合并所有的SSTables。当 compaction 是自动触发的时候，通常会运行得更好。禁用自动 compaction 手动触发 major compaction 很少是一个好主意。这里是为了教学目的而做的。

nodetool -p 7100 compact

现在，所有的SSTable已经合并成一个SSTable

alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 72
drwxr-xr-x  11 alain  staff   374 Jun 17 14:50 .
drwxr-xr-x   3 alain  staff   102 Jun 16 20:25 ..
drwxr-xr-x   2 alain  staff    68 Jun 16 17:05 backups
-rw-r--r--   1 alain  staff    51 Jun 17 14:50 mb-14-big-CompressionInfo.db
-rw-r--r--   1 alain  staff   105 Jun 17 14:50 mb-14-big-Data.db
-rw-r--r--   1 alain  staff    10 Jun 17 14:50 mb-14-big-Digest.crc32
-rw-r--r--   1 alain  staff    16 Jun 17 14:50 mb-14-big-Filter.db
-rw-r--r--   1 alain  staff    20 Jun 17 14:50 mb-14-big-Index.db
-rw-r--r--   1 alain  staff  4737 Jun 17 14:50 mb-14-big-Statistics.db
-rw-r--r--   1 alain  staff    61 Jun 17 14:50 mb-14-big-Summary.db
-rw-r--r--   1 alain  staff    92 Jun 17 14:50 mb-14-big-TOC.txt

这里是SSTable的内容，包含所有的墓碑，合并到同一个结构中，在同一个文件中。

alain$ SSTabledump /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big-Data.db
[
  {
    "partition" : {
      "key" : [ "apple" ],
      "position" : 0
    },
    "rows" : [
      {
        "type" : "range_tombstone_bound",
        "start" : {
          "type" : "exclusive",
          "clustering" : [ "20160615" ],
          "deletion_info" : { "marked_deleted" : "2016-06-17T09:14:11.697040Z", "local_delete_time" : "2016-06-17T09:14:11Z" }
        }
      },
      {
        "type" : "row",
        "position" : 40,
        "clustering" : [ "20160617" ],
        "deletion_info" : { "marked_deleted" : "2016-06-17T09:33:56.367859Z", "local_delete_time" : "2016-06-17T09:33:56Z" },
        "cells" : [ ]
      },
      {
        "type" : "range_tombstone_bound",
        "end" : {
          "type" : "inclusive",
          "deletion_info" : { "marked_deleted" : "2016-06-17T09:14:11.697040Z", "local_delete_time" : "2016-06-17T09:14:11Z" }
        }
      }
    ]
  },
  {
    "partition" : {
      "key" : [ "pickles" ],
      "position" : 73,
      "deletion_info" : { "marked_deleted" : "2016-06-17T09:38:52.550841Z", "local_delete_time" : "2016-06-17T09:38:52Z" }
    }
  }
]

请注意，此时被删除的数据在 compaction 过程中被直接删除。然而，正如前面所讨论的那样，我们仍然会在磁盘上存储一个墓碑标记，因为我们需要保留删除本身的记录，以便有效地将删除操作传达给集群的其他成员。我们不需要保留实际值，因为为了保持一致性，不需要这样做。

墓碑标记清除

Cassandra会在compaction触发时，只有在数据所属表上定义的local_delete_time + gc_grace_seconds之后，才会完全清理这些墓碑标记。请记住，所有的节点都应该在gc_grace_seconds内被修复，以确保墓碑标记的正确分布，并防止被删除的数据再次出现，如上所述。

这个gc_grace_seconds参数是数据被删除后，墓碑在磁盘上保留的最小时间。我们需要确保所有的副本也收到了删除，并且有墓碑存储，避免出现一些僵尸数据的问题。我们唯一的办法就是全面修复。在gc_grace_seconds之后，墓碑最终会被驱逐，如果有节点错过了墓碑，我们就会出现上面所说的情况，数据会重新出现。TTL不受此影响，因为没有一个节点可以拥有数据而错过相关的TTL，它是原子的，是同一个记录。任何拥有数据的节点也会知道数据什么时候要被删除。

另外，为了从磁盘中删除数据和墓碑，Cassandra代码还需要遵循其他安全规则。我们需要一行或一个分区的所有碎片都在同一个 Compaction 中，墓碑才能被删除。比如一个 Compaction 处理文件1到4，如果一些数据在文件5上，墓碑不会被驱逐，因为我们仍然需要它将SSTable 5上的数据标记为被删除，否则SSTable 5上的数据会回来（僵尸）。

这些条件有时会使删除墓碑成为一件非常复杂的事情。它常常给Cassandra用户带来很多麻烦。墓碑不被移除可能意味着使用了大量的磁盘空间，读取速度较慢，维修工作较多，GC压力较大，需要更多的资源等等。当你的一张表的大部分SSTables的墓碑比例很高的时候（90%的数据都是墓碑），就很难读到一个合适的值，一个相关的数据，存储成本就会比较高。这类问题甚至会导致磁盘空间的耗尽。

很多用法都会导致数据删除（TTL或deletes），这是我们作为Cassandra运维人员需要关注和处理的。

最后一次回到我们的例子。几天后我重启了节点（几天>10天，默认的gc_grace_seconds）。Cassandra打开了我们在mb-14-big上面建立的压缩SSTable，它马上就被压缩了。

MacBook-Pro:tombstones alain$ grep 'mb-14-big' /Users/alain/.ccm/Cassa-3.7/node1/logs/system.log

DEBUG [SSTableBatchOpen:1] 2016-06-28 15:56:17,947 SSTableReader.java:482 - Opening /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big (0.103KiB)
DEBUG [CompactionExecutor:2] 2016-06-28 15:56:18,525 CompactionTask.java:150 - Compacting (166f61c0-3d38-11e6-bfe3-e9e451310a18) [/Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big-Data.db:level=0, ]

此时由于gc_grace_seconds已经过了，墓碑是符合清理条件的。所以所有的墓碑都被删除了，由于这个表里已经没有数据了，所以数据文件夹现在终于空了。

MacBook-Pro:tombstones alain$ ll /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/
total 0
drwxr-xr-x  3 alain  staff  102 Jun 28 15:56 .
drwxr-xr-x  3 alain  staff  102 Jun 16 20:25 ..
MacBook-Pro:tombstones alain$

如果墓碑在所有的副本上都能正确复制，我们就会有一个完全一致的删除，不会再出现数据。这时我们还可以多释放一些磁盘空间，让我们更容易读取其他值，即使我的例子对于演示这个目的有点傻，因为现在表已经完全空了。

监控墓碑占比和过期

由于Cassandra设计的原因，在删除数据或使用TTL时出现墓碑是正常的，然而这是我们需要控制的。

要想知道一个表的墓碑率，或者想知道任何SSTable上墓碑清理时间（即删除时间戳）的估计分布，可以使用SSTablemetadata。

alain$ SSTablemetadata /Users/alain/.ccm/Cassa-3.7/node1/data/tlp_lab/tombstones-c379952033d311e6aa4261d6a7221ccb/mb-14-big-Data.db

--
Estimated droppable tombstones: 2.0
--
Estimated tombstone drop times:
1466154851:         2
1466156036:         1
1466156332:         1
--

上面展示的比例可能是错误的，因为在这个mb-14-big文件中，我有0个有用的行，只有墓碑的特定状态，但它通常是一个关于墓碑的SSTable状态的好指标。

另外，Cassandra通过JMX为所有表暴露了这个名为TombstoneScannedHistogram的监控指标。scope=tombstones 这样就是指定表：tombstones

org.apache.cassandra.metrics:type=Table,keyspace=tlp_lab,scope=tombstones,name=TombstoneScannedHistogram

这是值得纳入进监控工具的一个指标，如Graphite / Grafana，Datadog，New Relic等。

下面是我上面的例子在 Compaction 清理墓碑之前的jconsole输出。

单文件 compaction

在Jonathan Ellis在CASSANDRA-3442中报告了以下内容后，并在Cassandra 1.2中引入了单文件SSTable compaction。

在 sized tired compaction 的情况下，往往出现不经常执行 compaction 的大型SSTable文件。在这种情况下，如果混入了过期的数据，我们可能会浪费很多空间。

如上所述，compaction 负责墓碑清理工作。在某些情况下，compaction 无法做好墓碑的清理工作。不仅上述提到的 STCS 策略，其实目前所有的 compaction 策略都是如此。有些SSTables的 compaction 频率可能很低，或者有重叠的SSTables的时间很长。这就是为什么，现在所有的 compaction 策略都带有一套参数来帮助墓碑清理。

tombstone_threshold。这个参数的行为和Jonathan Ellis 在 2011 年所提交的 ticket 的描述的一模一样。

如果我们在SSTable元数据中保留一个TTL EstimatedHistogram，我们就可以对过期数据超过20%的SSTable进行单SSTable压实。

所以当认为可清理的墓石比例高于X（X=0.2，默认为20%）时，这个选项会触发一次单文件 compaction。因为计算出来的墓石比例没有考虑gc_grace_seconds所以往往实际能清理的墓碑会小于估计值。

tombstone_compaction_interval.这个选项在CASSANDRA-4781中被引入，当墓碑比例高到足以触发单文件 compaction 时，可能由于重叠 sstable 的因素导致墓碑实际上无法被清理，进而引起无限循环，这个选项就是为了解决这个问题引入的。我们必须确保删除所有的数据碎片以避免僵尸。在这种情况下，一些SSTable上会持续不断的进行 compaction。因为单文件的 compaction 触发条件仅仅基于墓碑率，而墓碑率是一个估计值。这个选项可以调整2个单文件 compaction 之间的最小间隔，默认是1天。

unchecked_tombstone_compaction。由Paulo Motta在CASSANDRA -6563中引入。这里是他对单SSTable历史的介绍，以及他引入这个参数的原因，非常有趣，我也无法解释得更好。

但是要注意 trade-off：把这个选项设置为true，只要墓碑比（估计）高于0.2（20%的数据是墓碑，墓碑_阈值默认），就会每天触发单文件 compaction（默认间隔：tombstone_compaction_interval），即使实际上没有一个墓碑是可以清理的。这将是最坏的情况。

所以，trade-off 是消耗更多的资源，期望能更好的完成墓碑清理。

建议：在一些数据中心遇到墓碑清理麻烦的时候，尽快给这个选项一个尝试应该是值得的。我有一些使用这个选项的成功经验，没有真正的坏经验，而是有一些情况下，这个改变没有真正的影响。我甚至在一些磁盘使用率达到100%的节点上将这个选项设置为true并且手动 compaction 正确的SSTables后，观测到磁盘使用率下降到一个合理的水位

要改变这些参数中的任何一个，先对你想要改的表使用 describe 命令，然后填写完整的 compaction 参数以避免任何问题。要改变tlp_lab键空间中表墓碑的 compaction 选项，我会这样做。

MacBook-Pro:~ alain$ echo "DESCRIBE TABLE tlp_lab.tombstones;" | cqlsh
CREATE TABLE tlp_lab.tombstones (
fruit text,
date text,
crates set<int>,
PRIMARY KEY (fruit, date)
) WITH CLUSTERING ORDER BY (date ASC)
AND bloom_filter_fp_chance = 0.01
AND caching = {'keys': 'ALL', 'rows_per_partition': 'NONE'}
AND comment = ''
AND compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4'}
AND compression = {'chunk_length_in_kb': '64', 'class': 'org.apache.cassandra.io.compress.LZ4Compressor'}
AND crc_check_chance = 1.0
AND dclocal_read_repair_chance = 0.1
AND default_time_to_live = 0
AND gc_grace_seconds = 864000
AND max_index_interval = 2048
AND memtable_flush_period_in_ms = 0
AND min_index_interval = 128
AND read_repair_chance = 0.0
AND speculative_retry = '99PERCENTILE';

然后，我复制 compaction 参数，并修改表格如下。

echo "ALTER TABLE tlp_lab.tombstones WITH compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4', 'unchecked_tombstone_compaction': 'true', 'tombstone_threshold': '0.1'};" | cqlsh

或者把以下内容写入脚本文件中执行。

ALTER TABLE tlp_lab.tombstones WITH compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4', 'unchecked_tombstone_compaction': 'true', 'tombstone_threshold': '0.1'};

cqlsh -f myfile.cql

也可以使用-e选项

cqlsh -e "ALTER TABLE tlp_lab.tombstones WITH compaction = {'class': 'org.apache.cassandra.db.compaction.SizeTieredCompactionStrategy', 'max_threshold': '32', 'min_threshold': '4', 'unchecked_tombstone_compaction': 'true', 'tombstone_threshold': '0.1'};"

注意：我使用其中一个选项，而不是进入cqlsh控制台，因为它更容易和 pipe 相结合。在选择数据或描述表时，它更有意义。想象一下，你需要检查你所有表的read_repair_chance情况

MacBook-Pro:~ alain$ echo "DESCRIBE TABLE tlp_lab.tombstones;" | cqlsh | grep -e TABLE -e read_repair_chance
    CREATE TABLE tlp_lab.tombstones (
        AND dclocal_read_repair_chance = 0.1
        AND read_repair_chance = 0.0
    CREATE TABLE tlp_lab.foo (
        AND dclocal_read_repair_chance = 0.0
        AND read_repair_chance = 0.1
    CREATE TABLE tlp_lab.bar (
        AND dclocal_read_repair_chance = 0.0
        AND read_repair_chance = 0.0

手动清理墓碑

有时候一些SSTables包含95%的墓碑，但由于 compaction 参数设置、SSTables重叠，或者仅仅是单SSTable compaction 的优先级低于常规 compaction，从而一直未能执行 compaction 操作。要知道，我们可以手动强制Cassandra运行用户定义的 compaction，这一点很重要。要做到这一点，我们需要能够通过JMX发送命令。我这里会考虑使用jmxterm。你可以选择自己喜欢的工具。

下载 jmxterm。

wget http://sourceforge.net/projects/cyclops-group/files/jmxterm/1.0-alpha-4/jmxterm-1.0-alpha-4-uber.jar

然后运行JMX命令，比如强制 compaction

echo "run -b org.apache.cassandra.db:type=CompactionManager forceUserDefinedCompaction myks-mytable-marker-sstablenumber-Data.db" | java -jar jmxterm-1.0-alpha-4-uber.jar -l localhost:7199

在某些情况下，我使用了基于这种命令的脚本，结合sstablemetadata工具给出的墓碑比例来搜索最差的文件，并将它们压缩，效果非常成功。

总结

针对分布式系统执行删除一直是一个棘手的操作，特别是当试图同时兼顾可用性、一致性和持久性时。

在像Apache Cassandra这样的分布式系统中，使用墓碑是一种执行删除的明智方式，但它也有一些注意事项。我们需要用一种非直观的方式来思考，因为在删除的时候，添加这块数据并不是一件自然的事情。然后了解墓碑的生命周期，这也不是小事。然而，当我们了解了墓碑的行为，并使用相应的工具来帮助我们解决墓碑问题时，墓碑也就变得容易理解了。

由于Cassandra是一个快速发展的系统，这里有一些正在进行的关于墓碑的提议，你可能有兴趣了解一下。

进行中提议：。

CASSANDRA-7019：改进墓碑 compaction（主要是解决SSTable墓碑重叠的问题，通过让单SSTable compaction 实际运行在多个智能选择的SSTables上）。

CASSANDRA-8527：凡是我们统计墓碑的地方都要考虑 range 类型的墓碑。看起来 range 类型的墓碑可能在代码的多个部分没有被很好地考虑。CASSANDRA-11166 和 CASSANDRA-9617 也指出了这个问题。

入群邀约
为了营造一个开放的 Cassandra 技术交流环境，社区建立了微信群公众号和钉钉群，为广大用户提供专业的技术分享及问答，定期开展专家技术直播，欢迎大家加入。

在这里插入图片描述
云 Cassandra
阿里云提供商业化Cassandra使用，支持中国站和国际站：
https://www.aliyun.com/product/cds

【译】深入浅出 Cassandra 的删除和墓碑

Cassandra：可用性 + 一致性

分布式删除的问题

从 Cassandra 单节点的角度看删除问题

墓碑

Cell 删除

Row 删除

Range 删除

Partition 删除

墓碑可能产生的问题

Compactions

墓碑标记清除

监控墓碑占比和过期

单文件 compaction

手动清理墓碑

总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景

热门

活动广场

任务中心

开发者评测

高校计划

乘风者计划

训练营

阿里云MVP

话题

直播

下载

镜像站

技术资料

插件

【译】深入浅出 Cassandra 的删除和墓碑

Cassandra：可用性 + 一致性

分布式删除的问题

从 Cassandra 单节点的角度看删除问题

墓碑

Cell 删除

Row 删除

Range 删除

Partition 删除

墓碑可能产生的问题

Compactions

墓碑标记清除

监控墓碑占比和过期

单文件 compaction

手动清理墓碑

总结

热门文章

最新文章

相关课程

相关电子书

相关实验场景