2

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

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

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

4

2 回答 2

2

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

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

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

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

Cassandra Wiki 状态[ 2 ]：

行键决定了存储机器数据的内容。

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

于 2010-07-28T07:42:20.890 回答
2

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

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

于 2010-12-06T14:58:48.870 回答