使用DyanmoDB行级访问控制时,如何避免热分区?

时间:2019-02-26 00:04:07

标签: amazon-web-services amazon-dynamodb database-partitioning

我正在考虑使用dynamodb:LeadingKeys向DynamoDB表添加行级权限,以限制对每个提供程序ID的访问。目前,我只有一个提供商ID,但我知道我会更多。但是,它们的提供者的大小会有所不同,因为这些大小非常不平衡。

如果我使用提供者ID作为分区键,那么在我看来,我的数据库最终将为大型提供者提供非常热的分区,而为小型提供者提供大部分未使用的分区。在添加行级访问控制之前,我使用deviceId作为分区键,因为它是一个更随机的名称,因此可以很好地进行分区,但是现在我想我必须将其移至排序键。

当前分区效果很好:

HASHKEY: DeviceId

获得权限后,我认为我需要访问:

HASHKEY: ProviderID (only a handful of them)
RangeKey: DeviceId

关于设置此方法的更好建议吗?

2 个答案:

答案 0 :(得分:0)

通常,您不再需要担心DynamoDB中的热分区,尤其是在被请求最多的分区键保持相对恒定的情况下。

更多信息:https://aws.amazon.com/blogs/database/how-amazon-dynamodb-adaptive-capacity-accommodates-uneven-data-access-patterns-or-why-what-you-know-about-dynamodb-might-be-outdated/

答案 1 :(得分:0)

扩大Michael的评论...

如果您现在不需要范围键...为什么要添加一个?

拥有范围键的唯一原因是您需要Query DDB并返回多个记录。

如果您所需要的只是使用GetItem的单个记录,则不需要范围键。

只需将${ProviderId}.${DeviceId}串联在一起即可构成您的哈希键。

修改
由于您希望能够列出单个提供程序的设备ID,因此您确实需要providerID作为分区键,并需要deviceID作为范围键。

正如Icehorn的答案所提到的,“热分区”已不再像以前那么重要了。除非您希望单个providerID的数据超过10GB,否则我将从简单实现hashKey(providerID)开始。

如果您期望超过10GB的数据,或者最终遇到了热分区...那么请考虑将(1..n)整数连接到providerID。

这意味着您必须查询多个分区才能获取所有设备ID。

此方法在Multi Tenant SaaS Storage Strategies

中有详细介绍