我对 DynamoDB 有疑问,或者更确切地说是如何为表建模。
问题描述:
目标:用户可以保存产品的价格提醒。
例如:用户希望在产品 x 的价格低于目标价格时保存提醒。
我具体要坚持的是:product, userId, targetPrice, operator。
运算符可以等于、小于或大于(我会在坚持之前的一个步骤中验证这些值)。
用户可以为目标价格和/或运算符(operator)不同的同一产品添加多个提醒。如果所有这些属性都相同,则不应在数据库中创建重复项。
当然,每个用户的警报应该完全分开。
我的主要“阅读”案例是获取产品的所有警报。
我目前的解决方案是将产品作为主键(每当我提到产品时,我都在谈论产品的唯一标识符)并将 alertId 作为排序键。
alertId 是所有属性的组合键:product:userId:targetPrice:operator
。
例如:greatBook12:1234:34:lesser
。
这里是 Node 中用于持久化警报的一些示例代码:
const params = {
TableName: TABLE_NAME,
Item: {
userId,
alertId: `${product}:${userId}:${targetPrice}:${operator}`,
product,
targetPrice,
operator
},
ReturnValues: 'ALL_OLD'
};
docClient.put(params) // ...
我的问题:
这样误用排序键感觉有点不对。虽然它确实涵盖了我的所有要求(没有重复,阅读很容易并且应该相对较快)但我想知道是否有更好的方法来做到这一点。也许有指数之类的?
我有点喜欢平面数据结构(只是表格中的项目),但也许还有另一种方法可以为不同的目标价格/运营商/产品/用户创建独特的警报而不创建重复项?
所以我想我的问题是:是否有更好的方法来满足我正在处理的要求?
非常感谢您!
最佳答案
非常有趣的问题。使用 product
分区键的一方面,您查询的是简单性,但您的数据分布也不均匀。如果一个产品将取得巨大成功并承担所有负载的 50%(此处详述“热分区”问题 https://cloudonaut.io/dynamodb-pitfall-limited-throughput-due-to-hot-partitions/)怎么办?在这种情况下,您可能会遇到读取或写入限制。 DynamoDB 建议使用一些随机性(例如随机值 (1, 1000))来避免这种不均匀分布。您可以在此处了解有关这些策略的更多信息:https://docs.aws.amazon.com/amazondynamodb/latest/developerguide/bp-partition-key-sharding.html#bp-partition-key-sharding-random
但这取决于您如何确定热分区风险。如果您确定没有它们(警报比其他产品多得多的产品),也许现在最好保持架构简单?
关于node.js - 为 DynamoDB 项目创建唯一 ID,我们在Stack Overflow上找到一个类似的问题: https://stackoverflow.com/questions/50587615/