我对DynamoDB有疑问，或者更确切地说是如何对表进行建模。
问题描述：
目标： 用户可以保存产品的价格提醒。
例如：用户想要保存产品 x 的价格低于目标价格时的警报。
我特别想坚持的是：产品，用户ID，目标价格，运算符。
运算符可以是相等的、更小的或更大的(我会在持久之前一步验证这些值(。
用户可以为目标价格和/或运营商不同的同一产品添加多个警报。如果所有这些属性都相同，则不应在数据库中创建重复的项目。
当然，每个用户的警报应该完全分开。
我的主要">阅读"案例是获取产品的所有警报。
我目前的解决方案是将产品作为主键(每当我提到产品时，我都在谈论产品的唯一标识符(并将 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
但这取决于您如何确定热分区风险。如果您确定没有它们(警报比其他产品多得多的产品(，也许现在最好保持架构简单？