1

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

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

它使用 3 个 ColumnFamilies。

我的问题是，PlayORM@NoSqlIndexed注释是如何实现的；就需要/创建哪些额外的 ColumnFamilies 而言？

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

4

2 回答 2

2

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

幻灯片 46 的问题，我不能得到误报吗？PlayOrm 也是如此。

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

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

  • server 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 它。

后来，迪恩

于 2013-03-01T15:06:01.513 回答
1

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

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

于 2013-03-01T10:41:36.603 回答