正如我经常说的，抱歉我的英语。我正在为Cassandra中的一些列族创建一些手动索引。我已经阅读了关于此的一切，但我发现了一些我无法正确理解的东西。
在Ed Anuff完成的演示文稿Indexing in Cassandra, pages 36 to 45中，我看到了他为Users列族创建索引的简单示例。他使用2个明显的CF和另一个来处理并发。第三个CF是“我的问题”。如果我没错，Cassandra将始终存储每列的最新值。如果这个值被索引，我必须在索引CF中更新它（删除旧索引并创建新索引），但为什么有必要使用第三个CF？当我想到这个和并发时，我的理解是：好的，很多人更新索引的值。这将意味着更新索引的大量工作，但最后的最后一个值将在用户CF和索引CF中，这就是每列有一个时间戳的原因，那么并发性的问题是什么？更重要的是，如果值只能由一个用户（数据的所有者）更新，那么就没有并发...
我知道我对Cassandra事务一无所知，但我没有看到第三个CF背后的原因。 Ed Anuff解释说，使用这个第三列系列，您可以将索引恢复到一致状态here，但是，为什么它们会陷入不一致状态？而且，如果发生这种情况，用户CF可能足以恢复索引，或者我错了吗？
拜托，有人可以解释一下吗？什么是我的错误/ s？
非常感谢！
答案 0 :(得分：0)
由于我认为其他人可能会遇到与我相同的疑问，我将用我发现的事情回答我自己的问题：
我认为主要问题是并发性。如果我们假设许多用户同时可以更改相同的索引值，因为您必须在更新之前读取索引，在您读取值的时间和更新索引中的值的时间之间，另一个用户可能已更改再次那个价值。同样，从更新值到更新索引的那一刻，系统可能会崩溃。然后，在几次并发更改之后，索引可能具有指向没有该值的行的旧值。
通过添加第三列系列，此过程更安全，但不是100％安全。
最后一件事：根据我的理解，如果在更新值时没有并发性，那么一定没有问题。让我们假设你正在索引一些用户数据。如果只允许数据的所有者修改数据，则根本没有并发性。唯一的风险是在完成流程以使索引与值对齐之前系统崩溃，但此操作是幂等的，因此您可以重复它直到成功。
希望这能解释我所理解并帮助他人的事。
答案 1 :(得分：0)
实际上我认为它更多是关于幂等性而不是并发性。 如果您有两个列族或三个，并发用户可能会产生误报结果，即索引列族中的键指向不再具有该值的行...但如果您重复任何行，则使用两个列族设计更新过程的一部分，您最终可能会丢失索引列系列正确行中的行的键...但是，如果使用三列族设计，您确定拥有每行的键索引列系列中的正确位置... 过滤结果将解决误报问题，但如果你没有正确的位置，你不能简单地获取行，整个索引机制将是徒劳的...
在两列族设计中考虑此示例： 用户1更新位置，Cassandra返回错误但写入成功。 用户2更新位置，读取用户1写入的结果并将其位置写入列族 用户1重新尝试并在列族中写入其位置并更新索引列族 用户2更新索引列族并删除用户1位置并插入自己的
最后一个用户具有用户1的位置，但行键仅存在于用户2输入索引行
中我现在就做了一个例子，它可能有一些问题，或者你可以通过改变更新过程来解决在正确的地方丢失密钥的问题，但你应该理解背后的概念。你可以想到一个更好的例子。
但是我不确定这一点，但这个解释对我来说很有意义，希望我可以向你解释......