它不会创建一个墓碑（不删除或故意写入null），但它会“过时”以前的值。
这意味着2009年的旧值和新值都将在读取时检索，cassandra将过滤掉除最近值以外的所有值。另外，这取决于从第一次写入到 teams ，新值和旧值完全有可能被写入单独的sstable文件，这意味着读取/协调过程将花费更长的时间。
因此，虽然这不会创建一个墓碑，但它会产生类似的效果，即大量过时的数据（从就地写入/更新）到相同的值将导致性能随着时间的推移而降低。

它不会创建墓碑，因为您正在用+更新集合。如果改为创建新集合，则会创建墓碑（在本例中是Map），如下所示：

UPDATE cycling.cyclist_teams SET teams = {2009 : 'DSB Bank - Nederland bloeit'} WHERE id = 5b6962dd-3f90-4c93-8f61-eabfa4a803e2

cassandra总是以append only模式写入数据，唯一的区别是，对于commit log，它被追加到日志的末尾，对于memtable，它是按照分区键和集群列的顺序写入的。memtables的数据定期刷新到sstable中。您的冲突数据最终可能会在sstable中重复（具有冲突的值）。事实上，所有插入都是upserts，除非用轻量级事务添加条件。
这两个值都将在读取时从a）行缓存（ram）、b）memtable（ram）或c）sstable（hdd/ssd）写入和检索，然后在发生冲突时，具有最新时间戳的数据将返回到驱动程序。取决于您的读取一致性级别-始终适用于任何 read_repair_chance 对于其他一致性级别-将更新副本memtables（ram）中的旧值。旧的（过时的）值最终将在sstable（hdd/ssd）压缩过程中删除。
您可以通过执行以下操作来试验并检索表统计信息，以查看是否存在任何逻辑删除：

$CASSANDRA_HOME/bin/nodetool cfstats keyspace.table