Cassandra 卡桑德拉支持什么类型的墓碑？

卡桑德拉（版本2）支持什么类型的墓碑？根据其支持的条款（以CQL术语）：

• 行的特定列
• 静态列
• 分区键的所有行

---

我错过了其他类型的墓碑吗？是否删除特定（CQL）行？是否有任何特殊的墓碑支持删除集群密钥或类似密钥的范围？当计划架构以避免过多的墓碑时，了解此信息非常有用。

墓碑是放置在一行中表示删除的标记。它们可以存在于不同的位置、一列或一系列列中，也可以存在于整行中。下面的示例显示了墓碑的正常类型（此处不包括范围类型）

在规划模式时，您可以根据正在执行的查询类型对表进行建模，而不是一个表，您可能会发现数据在多个表之间重复。这些表经过优化，以服务于传入的读写操作。下面的链接应该为您提供一些有关Cassandra数据建模的良好背景：

我的示例：我创建了一个表并插入了一些数据，然后使用

nodetool flush

生成了一些sstables。使用

sstable2json

工具，您可以看到已删除的行，如果是整行，它看起来与单列略有不同，但本质上它仍然只是一个标记：

以下是表格及其所有数据：

$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-1-Data.db 
[
{"key": "3136","columns": [["","",1417814256390000], ["col2","26",1417814256390000], ["col3","36",1417814256390000], ["id","id16",1417814256390000]]},
{"key": "3133","columns": [["","",1417814218246000], ["col2","23",1417814218246000], ["col3","33",1417814218246000], ["id","id13",1417814218246000]]},
{"key": "3135","columns": [["","",1417814244766000], ["col2","25",1417814244766000], ["col3","35",1417814244766000], ["id","id15",1417814244766000]]},
{"key": "3134","columns": [["","",1417814230711000], ["col2","24",1417814230711000], ["col3","34",1417814230711000], ["id","id14",1417814230711000]]},
{"key": "3132","columns": [["","",1417814207910000], ["col2","22",1417814207910000], ["col3","32",1417814207910000], ["id","id12",1417814207910000]]},
{"key": "3131","columns": [["","",1417814197094000], ["col2","21",1417814197094000], ["col3","31",1417814197094000], ["id","id11",1417814197094000]]},
{"key": "31","columns": [["","",1417814185270000], ["col2","2",1417814185270000], ["col3","3",1417814185270000], ["id","id1",1417814185270000]]}
]

以下是cqlsh中的第一次删除：

cqlsh:results> delete from ts1 WHERE col1 = '1';
cqlsh:results> delete id from ts1 WHERE col1 = '11';

cqlsh:results> delete col2 from ts1 WHERE col1 = '12';

以下是冲洗后产生的sstable：

[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-2-Data.db 
[
{"key": "3131","columns": [["id","54822130",1417814320400000,"d"]]},
{"key": "31","metadata": {"deletionInfo": {"markedForDeleteAt":1417814302304000,"localDeletionTime":1417814302}},"columns": []}
]

[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-3-Data.db 
[
{"key": "3132","columns": [["col2","5482220b",1417814539434000,"d"]]}
]

以下是cqlsh中的下一个删除：

cqlsh:results> delete from ts1 WHERE col1 = '1';
cqlsh:results> delete id from ts1 WHERE col1 = '11';

cqlsh:results> delete col2 from ts1 WHERE col1 = '12';

以下是冲洗后产生的sstable：

[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-2-Data.db 
[
{"key": "3131","columns": [["id","54822130",1417814320400000,"d"]]},
{"key": "31","metadata": {"deletionInfo": {"markedForDeleteAt":1417814302304000,"localDeletionTime":1417814302}},"columns": []}
]

[datastax@DSE3 ~]$ ~/dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-3-Data.db 
[
{"key": "3132","columns": [["col2","5482220b",1417814539434000,"d"]]}
]

当压缩发生时，所有这些sstable都合并到一个sstable中，然后被删除的行仍然存在，但标记为“要删除”，我们可以在运行压缩后再次看到这一点（查找带有时间戳的

d

标志）：

现在这个表将保持这样，直到我们达到

gc\u grace\u秒

，然后在下一次压缩时，行将实际消失，观察我们放下

gc\u grace\u秒

，然后运行压缩：

cqlsh> ALTER TABLE results.ts1 WITH gc_grace_seconds=500;
cqlsh> exit
[datastax@DSE3 ~]$ ./dse-4.5.1/bin/nodetool compact results;

[datastax@DSE3 ~]$ ./dse-4.5.1/resources/cassandra/bin/sstable2json ./dse-data/results/ts1/results-ts1-jb-5-Data.db 
[
{"key": "3136","columns": [["","",1417814256390000], ["col2","26",1417814256390000], ["col3","36",1417814256390000], ["id","id16",1417814256390000]]},
{"key": "3133","columns": [["","",1417814218246000], ["col2","23",1417814218246000], ["col3","33",1417814218246000], ["id","id13",1417814218246000]]},
{"key": "3135","columns": [["","",1417814244766000], ["col2","25",1417814244766000], ["col3","35",1417814244766000], ["id","id15",1417814244766000]]},
{"key": "3134","columns": [["","",1417814230711000], ["col2","24",1417814230711000], ["col3","34",1417814230711000], ["id","id14",1417814230711000]]},
{"key": "3132","columns": [["","",1417814207910000], ["col3","32",1417814207910000], ["id","id12",1417814207910000]]},
{"key": "3131","columns": [["","",1417814197094000], ["col2","21",1417814197094000], ["col3","31",1417814197094000]]}
]

注意键

31

的行是如何消失的，还有键

3132的行中的
col1
和键
3131的行中的
id

为了清晰起见，我的表格模式：

cqlsh:results> DESCRIBE TABLE ts1 ;

CREATE TABLE ts1 (
  col1 text,
  col2 text,
  col3 text,
  id text,
  PRIMARY KEY ((col1))
) WITH
  bloom_filter_fp_chance=0.010000 AND
  caching='KEYS_ONLY' AND
  comment='' AND
  dclocal_read_repair_chance=0.100000 AND
  gc_grace_seconds=864000 AND
  index_interval=128 AND
  read_repair_chance=0.000000 AND
  replicate_on_write='true' AND
  populate_io_cache_on_flush='false' AND
  default_time_to_live=0 AND
  speculative_retry='99.0PERCENTILE' AND
  memtable_flush_period_in_ms=0 AND
  compaction={'class': 'SizeTieredCompactionStrategy'} AND
  compression={'sstable_compression': 'LZ4Compressor'};

作为脚注，
sstable2json
输出中的墓碑标记如下：

e
-已过期的TTL

d
-删除值（墓碑）

t
-删除了值的范围（范围墓碑）
除了@markc的答案之外，还有一个列范围墓碑，每当您使用集合时都会显示出来。我们有一个名为“tags”的
set
列，每当我们插入一行时，我们都会得到其中一行（即使我们只是像本例中那样将其设置为null）：

我们认为“t”代表墓碑。详细介绍了这种墓碑的另一个例子。
这是一个很好的解释，说明了墓碑“在引擎盖下”的样子。做得很好！有趣。为了清楚起见，您是否介意发布表架构？另外，在您第一次删除（和刷新）之后，我是否应该在生成的墓碑中看到对“1”和/或“11”的引用？我很困惑。嗨，很抱歉给你带来困惑，请接受我的道歉。只有在gc_宽限期_秒过期后，行才会真正消失。我现在已经编辑了我的文章，应该更清楚了。如果你还不清楚，请一定告诉我。谢谢“t”实际上是一个范围墓碑。请参阅此链接：