我对DynamoDB有疑问,或者更喜欢如何建模表. 问题描述: 目标:用户可以保存产品的价格提醒. 例如:用户希望在产品x的价格低于目标价格时保存警报. 我想要具体坚持的是:product,userI
问题描述:
目标:用户可以保存产品的价格提醒.
例如:用户希望在产品x的价格低于目标价格时保存警报.
我想要具体坚持的是:product,userId,targetPrice,operator.
运算符可以相等,更少或更大(我会在持久化之前在一个步骤中验证这些值).
用户可以为targetPrice和/或操作符不同的同一产品添加多个警报.如果所有这些属性都相同,则不应在db中创建重复项.
当然,每个用户的警报应该完全分开.
我的主要“阅读”案例是获取产品的所有警报.
我目前的解决方案是将产品作为主键(每当我提到产品而不是我谈论产品的唯一标识符时)和alertId作为排序键.
alertId是所有属性的组合键:product:userId:targetPrice:operator.
例如:greatBook12:1234:34:较小.
这是节点中用于保持警报的一些示例代码:
const params = { TableName: TABLE_NAME, Item: { userId, alertId: `${product}:${userId}:${targetPrice}:${operator}`, product, targetPrice, operator }, ReturnValues: 'ALL_OLD' }; docClient.put(params) // ...
我的问题:
滥用类似的排序键感觉有点不对.虽然它确实涵盖了我的所有要求(没有重复,阅读很容易,而且应该相对较快)我想知道是否有更好的方法来做到这一点.也许有指数等?
我有点像平面数据结构(只是表格中的项目)但也许还有另一种方法可以为不同的targetPrices /操作符/产品/用户创建独特的警报而不会产生重复数据?
所以我想我的问题是:在满足我正在使用的要求的同时,有更好的方法吗?
非常感谢你提前!
非常有趣的问题.从产品分区键的一侧,您可以查询简单性,但您也不均衡地分配数据.如果一个产品取得巨大成功并占据所有负载的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但这取决于你如何确定热门分区的风险.如果您确定没有它们(产品的警报比其他产品多得多),那么现在最好保持模式简单吗?