如何解决使用低基数的排序键有什么缺点?
对于我的表,我具有以下属性:
- ItemId
- 产品名称
只有ItemId + ProductName是唯一的。但是ItemId具有非常高的基数,并且实际上是唯一的,只是不能保证。 ProductName的基数非常低(〜5个不同的值)。 客户将始终传递ItemId + ProductName来获取商品。
方法1
最初我想将主键的分区键设置为ItemId + ProductName(字符串concat)。
方法2
但是,由于创建表后不能更改主键,因此我考虑将排序键保留为占位符。因此,将(复合)主键的分区键设置为ItemId,将排序键设置为ProductName。
好处是万一我想将来将东西添加到排序键中(例如版本号),我可以在不迁移表的情况下做到这一点。虽然现在我看不到要添加的内容。
但是,与方法1相比,方法2保持原样(排序关键字是低基数)有什么缺点(例如性能)?
解决方法
如果您使用按需定价,那么这应该对价格/性能没有影响。
如果没有,那么通常会有一些差异:https://blog.yugabyte.com/11-things-you-wish-you-knew-before-starting-with-dynamodb/
预留空间来处理热分区。
在DynamoDB中,预配置的IOPS总数平均分配给所有 分区。因此,选择一个 分区键将平均分布读写 这些分区。如果一个表最后有几个热分区,那 需要更多IOPS,预配置的总吞吐量必须足够高,因此 所有分区都配备了所需的吞吐量 最热的分区。这会导致成本急剧增加,并且 沮丧的工程师。
在您的特定情况下,它也不起作用。
,很难说,不知道您期望多少音量...
通常,您需要具有高基数的分区键。排序键基数通常无关紧要。
但是,如果您预计少量的itemId将获得最多的流量,则可能会遇到“热分区”问题;尽管风险为greatly reduced now-a-days。
此外,仅当DDB表首先分区时,热分区才是问题。当存储空间超过10GB *或所需的RCU / WCU分别超过3000/1000时,DDB将对数据进行分区。
*甚至不能保证10GB,没有本地二级索引的DDB表的分区可以大于10GB。
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。