我正在为 PenWag.com 进行从 MySQL 到 Cassandra 的转换。在 Cassandra 中，我存储通过 GUID 关闭的用户，但用户使用他们的电子邮件登录，而不是 GUID(显然)。 GUID 作为用户的 key 对我来说比电子邮件更有意义，原因有两个。从实际角度来看，更改或删除/添加一行及其所有 super 列似乎太麻烦了。从理论上讲，仍然是同一个用户，为什么他们的 key 要改变？
尽管如此，我的问题是:我正在单独的 ColumnFamily 中构建索引，映射电子邮件->GUID 以支持登录。它是标准类型 CF，其中列名称为 email，值为 GUID。这是标准，而不是 super ，以避免为每个映射加载整个 SC。支持“更改电子邮件”很简单，只需删除/添加列即可。但似乎替代方案是将索引存储为行而不是列，其中行键是电子邮件，列保存 GUID。删除/添加这些行不会很麻烦，因为只有列(GUID)需要管理。
看来这两种方法都有效。各自的优点和缺点是什么？有最佳实践吗？
最佳答案
由于我没有 Cassandra 或类似数据库的实践经验，因此您需要对我的回答持保留态度:)
如果您将每个映射存储为一列，并使用电子邮件地址作为列名称，则这意味着单行包含大量列。根据维基百科[ 1 ]:
Every operation under a single row key is atomic per replica no matter how many columns are being read or written into.
如果所有映射都存储在单行中，这可能会导致大量的锁定开销。
Cassandra Wiki 指出[ 2 ]:
The row key is what determines what machine data is stored on.
这让我相信根据行键进行查找比根据列名进行查找更有效。根据此信息，我建议使用电子邮件地址作为行键并将 GUID 存储在列中。
关于nosql - Cassandra/BigTable 数据模型 - 构建索引的最佳方法是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/3318773/