您可以在没有锁定的情况下进行并发更新。
幻灯片 46 的问题,我不能得到误报吗? PlayOrm 也是如此。
需要注意的是,您可能需要在阅读时解决问题。例子是这样的。假设您在数据库中有一个地址为 123 的 Fred。
现在,两台服务器对 Fred 进行了更新
- 服务器1:Fred的新地址是456(导致删除索引123.fred,增加456.fred)
- server 2 : Fred 的新地址是 789(导致删除索引 123.fred 并添加 789.fred)
这意味着您的索引可能有 456.fred 和 789.fred 的副本。然后,您可以在读取时解决此问题,因为当您询问地址为 456 的人时,查询将返回 Fred。我们还有另一张票可以在读取时为您解决此问题;)并消除该条目。
我们确实询问过在 cassandra 中我们可能做的更改(添加列 456.fred IF 列 123.fred 存在或失败),但不确定他们是否会实现类似的东西。这会将失败传播给失败者(即最后一个作家得到例外)。这会很好,但我不确定他们会做这样的功能。
注意:与 CQL 不同,查询不会发送到所有节点。它只将负载放在包含索引的节点上,而不是所有 100 台计算机上。 IE。这样可以更好地扩展。
更多细节:在该演示文稿的第 27 张幻灯片上,您的链接具有几乎与我们的索引类似的内容。该格式不包含 1、2、3。索引格式为
Indexes=
{"User_Keys_By_Last_Name":{
{"adams","e5d…"}: null,
{"alden","e80…"}: null,
{"anderson","e5f…"}: null,
{"anderson","e71…"}: null,
{"doe","e78…"}: null,
{"franks","e66…"}: null,
…:…,
}
}
这样,我们可以避免读取来确定是否需要在名称的后半部分使用 1、2、3、4、5。相反,我们使用我们知道是唯一的 FK 并且只需要进行写入。无论如何,Cassandra 都是关于解决读取冲突的,这就是存在修复过程的原因。这是基于这样一个事实,即冲突发生的时间比例非常低,并且只会在那个低比例时受到打击。
最后,您可以使用命令行工具查看索引!!!!它将大约 200 列中的内容批处理,每列流回,因此您可以拥有 100 万个条目,并且命令行工具会很高兴地继续打印它们,直到您 ctrl-c 它。
后来,
院长