【发布时间】:2015-11-17 13:05:52
【问题描述】:
我们在 cassandra 中使用社交登录对帐户表进行建模,我们选择电子邮件作为主键和瘦行实现。我们的 cassandra 版本为 2.1.6。这是表定义:
CREATE TABLE account_by_email (
email_address text,
account_password text,
first_name text,
last_name text,
registered_at timestamp,
roles set<text>,
facebook_id text,
twitter_id text,
linkedin_id text,
password_reset_token blob,
password_reset_token_valid_until timestamp,
profile_image_url text,
PRIMARY KEY (email_address) ) WITH COMMENT='Accounts in system by email.';
这对于电子邮件访问来说很好,因为当我们知道登录后的电子邮件地址时,我们可以快速访问每个帐户。
除了电子邮件登录选项外,用户还可以使用社交帐户登录/注册。当使用社交帐户登录时,流程是转到社交网络,接收社交 ID(facebook、twitter、linkedin),可能还有电子邮件并通过社交 ID 查询帐户表以获取完整帐户,或者只是电子邮件并继续在每个 API 请求上使用电子邮件。
我们目前在facebook_id、twitter_id、linkedin_id 上添加了索引来支持这一点,因为我们处于 MVP 阶段,只有一个节点,我们选择 fats 实现而不是性能。
对此建模的正确方法是什么?以下是我们正在考虑的几个建议:
- 离开索引实施,因为通过社交 ID 获取仅在登录一次时发生(在使用该电子邮件之后)
- 每个社交 ID 都有一个表格,用于保存社交 ID 电子邮件对
- 为每个社交 ID 设置一个表格,用于保存完整帐户(帐户可以编辑,这样会增加更新的复杂性)
- 还有别的吗?
还有一个问题,当您对很少发生的访问路径进行建模时,具有高基数字段(如社交 ID)的索引实现真的那么糟糕吗?
【问题讨论】:
标签: cassandra data-modeling datastax-java-driver cassandra-2.1