为什么 Cassandra UPDATE 不违反写前不读规则答案

【问题标题】：Why doesn't Cassandra UPDATE violate the no read before writes rule为什么 Cassandra UPDATE 不违反写前不读规则
【发布时间】：2015-07-06 15:31:52
【问题描述】：

我对关于 Cassandra 的两个看似矛盾的陈述感到困惑

在写入之前没有读取（可能是因为写入是顺序的，而读取需要扫描主键索引）
INSERT 和 UPDATE 具有相同的语义（在 CQL manual 的 older version 中说明，但可能仍被认为基本正确）

假设我创建了以下简单表格：

CREATE TABLE data (
  id varchar PRIMARY KEY,
  names set<text>
);

现在我插入一些值：

insert into data (id, names) values ('123', {'joe', 'john'});

现在，如果我进行更新：

update data set names = names + {'mary'} where id = '123';

结果如预期：

 id  | names
-----+-------------------------
 123 | {'joe', 'john', 'mary'}

这不是必须先读再写的情况吗？ “成本”似乎如下

阅读专栏的成本
创建两个集合并集的成本（此处可以忽略不计，但使用较大的集合可能会很明显）
使用键和新列数据写入数据的成本

插入只是做这些中的最后一个。

【问题讨论】：

标签： cassandra-2.0 cqlsh

【解决方案1】：

写之前不需要读。
在每个集合内部，每个条目使用一列存储数据——当您在集合中请求新条目时，操作在单个列中完成*：如果该列已经存在，它将被覆盖，否则将被创建（ InsertOrUpdate)。这就是为什么集合中的每个条目都可以具有自定义 ttl 和 writetime 的原因。

*虽然Map 和Set 是透明的，但有一些内部技巧允许在List 内有多个具有同名的列。

【讨论】：

如果我理解正确你的意思是我上面的插入和更新只是两个插入。第一个用 {'joe', 'john'} 建立一列，第二个用值 {'mary'} 建立一个全新的列。这些在一个列（名称）中呈现为一组，实际上是对实际上是多列的视图。
部分正确。第一个插入建立 2 个新列，而不是一个。如果您再次执行更新操作，您将用新的写入时间覆盖最后一列（玛丽）。在任何情况下都没有读取