我正在构建一个DynamoDB应用程序,该应用程序最终将为大量(数百万)用户提供服务。目前,应用程序的项目架构很简单:
{
userId: "08074c7e0c0a4453b3c723685021d0b6", // partition key
email: "foo@foo.com",
... other attributes ...
}
当新用户注册时,或者如果一个用户想要通过电子邮件地址找到另一个用户,我们将需要按email
而不是userId
查找用户。使用当前的模式很容易:只需使用带有email
作为分区键的全局二级索引即可。
但是我们想为每个用户启用多个电子邮件地址,并且DynamoDB Query
操作不支持List
类型的KeyConditionExpression
。因此,我正在权衡几种选择,以避免每次用户注册或希望通过电子邮件地址找到另一个用户时进行昂贵的Scan
操作。
以下是我打算更改的功能,以为每个用户启用其他电子邮件。这是一个好方法吗?有更好的选择吗?
itemTypeAndIndex
)以允许每个userId
有多个项目。 {
userId: "08074c7e0c0a4453b3c723685021d0b6", // partition key
itemTypeAndIndex: "main", // sort key
email: "foo@foo.com",
... other attributes ...
}
{
userId: "08074c7e0c0a4453b3c723685021d0b6", // partition key
itemTypeAndIndex: "Email-2", // sort key
email: "bar@bar.com"
// no more attributes
}
相同的全局二级索引(使用email
作为分区密钥)仍可用于查找主要和非主要电子邮件地址。
如果用户想更改其主要电子邮件地址,我们将在“主要”和“非主要”项目中交换email
值。 (现在DynamoDB支持transactions,这样做会比以前更安全!)
如果我们需要删除用户,则必须删除该userId
的所有项目。如果我们需要合并两个用户,则必须合并该userId
的所有项目。
可以将相同的方法(具有相同userId
但排序键不同的新项目)用于需要Query
的其他1-user-has-man-values数据
这是一个好方法吗?有更好的方法吗?
答案 0 :(得分:1)
Justin,在搜索属性时,我强烈建议不要使用DynamoDB。我并不是说,您无法实现这一目标。但是,如果您扎根,我发现最终会遇到一些问题。
因此,随着搜索条件用例的增加,该解决方案将很容易成为您系统的瓶颈。因此,您的系统可能无法很好地扩展。
据我所知,我可以根据您的要求/预算建议一些选项,以使用多个数据库来解决此问题。
Option 1.
DynamoDB作为主要存储,AWS Elasticsearch作为辅助存储[首选]
现在,在您的应用程序中,使用DynamoDB从ID中获取用户记录。对于所有其他搜索条件(例如搜索emailId,电话号码,邮政编码,位置等),请从AWS Elasticsearch获取记录。默认情况下,AWS Elasticsearch对记录的所有属性建立索引,因此您可以在延迟的毫秒内搜索任何字段。
Option 2.
使用AWS Aurora [更少的首选解决方案]
如果您的应用程序具有与数据相关的关系用例,则可以考虑使用此选项。只是请注意,Aurora是一个SQL数据库。 由于这是一个关系存储,因此您可以选择组织多个表中的记录,并根据这些表的主键将它们连接起来。
我建议第一种选择为:
话虽如此,现在我将由您决定。