问题描述：

目标：用户可以保存产品的价格提醒。

例如：用户希望在产品x的价格低于目标价格时保存提醒。

我想要具体坚持的是： product，userId，targetPrice，operator 。

运算符可以相等，更小或更大（我会在持久化之前对这些值进行验证）。

用户可以为targetPrice和/或运营商不同的同一产品添加多个警报。如果所有这些属性都相同，则不应在db中创建重复项。

当然，每个用户都应完全分开警报。

我的主要＆＃34; 阅读＆＃34;案例是获取产品的所有警报。

我目前的解决方案是将产品作为主键（每当我提及产品时，而不是我所说的产品的唯一标识符）和alertId作为排序键。

alertId是所有属性的复合键：product:userId:targetPrice:operator。

例如：greatBook12:1234:34:lesser。

这是节点中用于保持警报的一些示例代码：

const params = {
  TableName: TABLE_NAME,
  Item: {
    userId,
    alertId: `${product}:${userId}:${targetPrice}:${operator}`,
    product,
    targetPrice,
    operator
  },
  ReturnValues: 'ALL_OLD'
};
docClient.put(params) // ...

我的问题：

像这样滥用排序键感觉有点不对。虽然它确实涵盖了我的所有要求（没有重复，阅读很容易，而且应该相对较快）我想知道是否有更好的方法来做到这一点。也许有指数等？

我有点像平面数据结构（只是表格中的项目）但也许还有另一种方法可以为不同的targetPrices /运营商/产品/用户创建独特的警报而不会产生重复数据？

所以我想我的问题是：在满足我正在使用的要求的同时，有更好的方法吗？

非常感谢您提前！

Answer 1

非常有趣的问题。从一侧使用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

但这取决于您如何确定热门分区的风险。如果您确定没有它们（产品的警报比其他产品多得多），那么现在最好保持模式简单吗？

为DynamoDB项创建唯一ID

问题描述：

我的问题：

1 个答案: