Question

对于处理并发更新的二级索引，有几种自己的策略，例如：

http://www.slideshare.net/edanuff/indexing-in-cassandra

使用3个ColumnFamilies。

我的问题是，PlayORM @NoSqlIndexed注释是如何实现的;就需要/创建多少ColumnFamilies而言？

此外，是否支持并发更新 - 即，两个竞争更新不可能从一个更新索引和从另一个更新表？

Answer 1

您可以在没有锁定的情况下进行并发更新。

Slide 46的问题我不能得到误报吗？是与PlayOrm相同的情况。

一个警告是你可能需要在阅读时解决。因此是一个例子。假设您在数据库中拥有地址为123的Fred。

现在，两台服务器对Fred进行了更新

服务器1：Fred的新地址是456（导致删除索引123.fred并添加456.fred）
服务器2：Fred的新地址是789（导致删除索引123.fred并添加789.fred）

这意味着您的索引可能有456.fred和789.fred的副本。然后，您可以在读取时解决此问题，因为当您要求地址为456的人时，查询将返回Fred。还有另一张票可供我们解决此问题;并删除条目。

我们确实询问过我们可能做的cassandra的更改（添加列456.fred IF列123.fred存在或失败）但不确定他们是否会实现类似的东西。这会将失败传回失败者（即最后一位作家获得例外）。这会很好，但我不确定他们会做这样的功能。

BIG注意：与CQL不同，查询不会发送到所有节点。它只会将负载放在包含索引的节点上，而不是所有100台计算机上。即。它可以通过这种方式更好地扩展。

更详细信息：在您的链接所显示的幻灯片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万个条目，命令行工具很乐意继续打印它们，直到你按下它为止。

后，迪安

Answer 2

截至目前，只为Playorm中的所有索引创建了3个表。即，所有索引都存储在StringIndice，IntegerIndice和DecimalIndice列族中。

除此之外，还有一种正在开发的模式，如果需要，它将为该列创建一个新表。请参阅https://github.com/deanhiller/playorm/issues/44上的模式详细信息。

如何在PlayORM中实现二级索引并支持/处理并发更新？

2 个答案: