0

正如我常说的，对不起我的英语。我正在为 Cassandra 中的某些列族创建一些手动索引。我已经阅读了有关此的所有内容，但我发现了一些我无法正确理解的内容。

在本演示文稿中，在 Cassandra 中编制索引，第 36 至 45 页，由 Ed Anuff 完成，我看到了他为用户列族创建索引的简单示例。他使用 2 个明显的 CF 和另一个来处理并发。这第三个 CF 是“我的问题”。如果我没记错的话，Cassandra 将始终存储每列的最新值。如果这个值被索引了，我必须在索引 CF 中更新它（删除旧索引并创建新索引），但为什么需要第三个 CF？当我考虑到这一点和并发性时，我的理解是：好的，很多人更新了一个被索引的值。这将意味着更新索引的大量工作，但最后一个值将在用户 CF 和索引 CF 中，这就是为什么每列都有一个时间戳，那么并发有什么问题呢？更，

我知道我对 Cassandra 事务非常无知，但我不明白第三个 CF 背后的原因。Ed Anuff 解释说，使用第三列族，您可以将索引恢复到此处的一致状态，但是，为什么它们会陷入不一致状态？而且，如果发生这种情况，用户 CF 可能足以恢复索引，还是我错了？

拜托，有人可以解释一下吗？什么是/是我的错误/s？

非常感谢你！

4

2 回答 2

0

由于我认为其他人可能与我有同样的疑问，我将用我发现的东西来回答我自己的问题：

正如我认为的主要问题是并发性。如果我们假设许多用户可以同时更改相同的索引值，因为您必须在更新之前读取索引，那么在您读取值和更新索引中的值之间，另一个用户可能已经更改又是那个值。此外，从值更新到更新索引的那一刻，系统可能会崩溃。然后，在一些并发更改之后，索引可能具有指向没有该值的行的旧值。

通过添加第三个色谱柱系列，此过程更安全，但不是 100% 安全。

最后一件事：据我了解，如果更新值时没有并发，那么肯定没有问题。假设您正在索引一些用户数据。如果只允许数据的所有者修改数据，那么根本就没有并发。唯一的风险是在您完成将索引与值对齐的过程之前系统崩溃，但此操作是幂等的，因此您可以重复它直到成功。

希望这能解释我所理解的并帮助其他人。

于 2013-02-01T17:01:03.100 回答
0

实际上，我认为这更多是关于幂等性而不是并发性。如果您有两个或三个列族，并发用户可能会产生误报结果，即索引列族中的键指向不再具有该值的行...但是如果您重复任何列族设计，则使用两个列族设计更新过程的一部分，您最终可能会丢失索引列族的正确行中的行的键...但是通过三列族设计，您可以确定每行的键在索引列族中的正确位置...过滤结果将解决误报问题，但是如果您没有正确位置的键，则无法简单地获取行，整个索引机制将是徒劳的...

考虑一个两列族设计的示例：用户 1 更新位置，Cassandra 返回错误但写入成功。用户 2 更新位置，读取用户 1 的结果写入并将其位置写入列族 用户 1 重试并将其位置写入列族并更新索引列族 用户 2 更新索引列族并删除用户 1 位置并插入他自己

最后用户拥有用户 1 的位置，但行键仅存在于用户 2 输入索引行中

我现在做这个例子，它可能有一些问题，或者你可以通过改变更新过程来解决在正确的地方丢失密钥的问题，但是你应该理解背后的概念。你可以想一个更好的例子。

但是我不确定这一点，但这个解释对我来说很有意义，希望我能向你解释......

于 2013-09-01T12:41:37.280 回答