Cassandra/BigTable 数据模型 - 构建索引的最佳方法是什么？

Question

我正在为 PenWag.com 进行从 MySQL 到 Cassandra 的转换。在 Cassandra 中，我存储的是使用 GUID 键控的用户，但用户使用他们的电子邮件登录，而不是 GUID（显然）。 GUID 作为用户的键对我来说比电子邮件更有意义，原因有两个。从实际的角度来看，更改或删除/添加包含所有 SuperColumns 的行似乎太麻烦了。从理论上讲，仍然是同一个用户，为什么要改变他们的密钥？

不过，这是我的问题：我正在单独的 ColumnFamily 中构建索引，映射电子邮件->GUID 以支持登录。这是一个标准类型的 CF，其中列名是电子邮件，值是 GUID。避免为每个映射加载整个 SC 是标准的，而不是超级的。支持“更改电子邮件”很容易，它只是一个列删除/添加。但似乎另一种方法是将索引存储为行而不是列，其中行键是电子邮件，列保存 GUID。删除/添加这些行不会很麻烦，因为只有列（GUID）要管理。

似乎这两种方法都有效。各自的优缺点是什么？有最佳做法吗？

Answer 1

由于我没有使用 Cassandra 或类似数据库的实践经验，因此您需要对我的回答持保留态度 :)

如果您将每个映射存储为一列，并使用电子邮件地址作为列名，这意味着单行包含大量列。根据维基百科^[1]：

无论读取或写入多少列，单个行键下的每个操作都是每个副本的原子操作。

如果所有映射都存储在一行中，这可能会导致显着的锁定开销。

Cassandra Wiki 声明^[2]：

行键决定了存储机器数据的位置。

这让我相信基于行键的查找比基于列名的查找效率更高。基于此信息，我建议使用电子邮件地址作为行键并将 GUID 存储在列中。

Answer 2

尼尔斯是正确的；每个用户一行是手动执行此操作的正确方法。

我有资格这样做，因为在 0.7 中，您可以在行中有一个电子邮件列，其中包含其余的按 UUID 键控的用户数据，并要求 Cassandra 对其进行索引：http://www.riptano.com/blog/whats-new-cassandra-07-secondary-indexes