Cassandra的这种行为似乎没有记录在案，违反直觉。我想知道为什么会发生这种情况，以及如何防止这种情况。
创建测试表。
CREATE TABLE test_table (id text PRIMARY KEY, foo text);现在在表中创建一行 USING TIMESTAMP .
INSERT INTO test_table (id, foo)
VALUES ('first', 'hello')
USING TIMESTAMP 1566912993048082;结果是
id | foo | writetime(foo)
-------+-------+------------------
first | hello | 1566912993048082现在让我们使用相同的时间戳更新行。
INSERT INTO test_table (id, foo)
VALUES ('first', 'hello2')
USING TIMESTAMP 1566912993048082;一切正常。
id | foo | writetime(foo)
-------+--------+------------------
first | hello2 | 1566912993048082让我们使用相同的时间戳再次更新行。
INSERT INTO test_table (id, foo)
VALUES ('first', 'hello1')
USING TIMESTAMP 1566912993048082;!!! 什么都没变。
id | foo | writetime(foo)
-------+--------+------------------
first | hello2 | 1566912993048082再次更新同一行。
INSERT INTO test_table (id, foo)
VALUES ('first', 'hello3')
USING TIMESTAMP 1566912993048082;!!! 又起作用了。
id | foo | writetime(foo)
-------+--------+------------------
first | hello3 | 1566912993048082似乎只有在 old.foo < new.foo 使用相同的时间戳。
预期结果：
更新不会使用相同的时间戳进行
更新总是使用相同的时间戳进行
实际结果：
有时使用相同的时间戳进行更新
1条答案
按热度按时间yqhsw0fo1#
仅供参考，
我开了张罚单想得到你问题的答案。以下是其他可能尝试这种方法的人的React。同样，在一个典型的情况下，一个人不会做你正在做的事情。
----回应----
如您所知，dse/cassandra通过写入时间戳处理冲突，其中最新的总是获胜。在你的思维实验中详细描述的情况下，实际上有两种情况需要处理。
活细胞与墓碑相撞在这种情况下墓碑将永远获胜。无法知道这是否是客户所期望的，但行为将是一致的。
活细胞与另一个活细胞相撞的情况类似于墓碑上的情况，我们无从知道应该归还哪个细胞。为了提供一致性，当写入时间戳相同时，值越大越好。