我的应用程序打算在 DynamoDB 表中存储项目列表。被选中的 分区键是每个项目的唯一 GUID，它支持所有访问模式 该应用程序今天需要。
| PK | 商品名称 |
|---|---|
| c2401dc9-7e6f-4bd5-93bf-b2643314c3b4 | 商品编号1 |
| 00157505-7a9e-488a-83dd-602da786c9ac | 商品编号2 |
| 0342a419-3fed-4284-babd-5dfc3748e6ab | 商品编号3 |
当然，今天表上有一个分区键就足够了。但我想知道 为什么我不想添加排序键以防我的访问模式发生变化？ 显然，DynamoDB 不允许更改现有表的键 未来。
这就是我想存储数据的方式：
| PK | SK | 商品名称 |
|---|---|---|
| c2401dc9-7e6f-4bd5-93bf-b2643314c3b4 | 细节 | 商品编号1 |
| 00157505-7a9e-488a-83dd-602da786c9ac | 细节 | 商品编号2 |
| 0342a419-3fed-4284-babd-5dfc3748e6ab | 细节 | 商品编号3 |
明天，如果我的应用程序需要更复杂的访问模式，我的手将会 打开以开始引入新的排序键。例如版本控制系统：
| PK | SK | 商品名称 | 版本 |
|---|---|---|---|
| c2401dc9-7e6f-4bd5-93bf-b2643314c3b4 | 细节 | 商品编号1 | |
| 00157505-7a9e-488a-83dd-602da786c9ac | 细节 | 商品编号2 | |
| 0342a419-3fed-4284-babd-5dfc3748e6ab | 细节 | 商品编号3 | |
| ea2b656a-5fb2-483f-8ad8-59d3f82605ab | 细节 | 商品编号4 | |
| ea2b656a-5fb2-483f-8ad8-59d3f82605ab | 版本#1 | 商品编号4 | |
| ea2b656a-5fb2-483f-8ad8-59d3f82605ab | 版本#2 | 商品编号4 | |
| ea2b656a-5fb2-483f-8ad8-59d3f82605ab | 版本#3 | 商品编号 4 | |
| ea2b656a-5fb2-483f-8ad8-59d3f82605ab | 版本 | 3 |
在我看来，后者显然是赢家。我不明白为什么我不想 即使我的应用程序最终根本不需要它，也有一个排序键。有什么害处 无论如何？
如果有我不知道的相关费用，请您告诉我 为什么我应该坚持以前的方法？
你是对的，创建表后就无法更改主键。除了与额外字节相关的存储和吞吐量成本之外，拥有不需要的排序键并没有真正的缺点，只是为了将来证明您的表。
根据您的描述，它为您的项目添加了 8-10 个字节。由整个数据集组成，可能会增加数百万或数十亿个项目的存储成本。但这是微不足道的。从吞吐量的角度来看，添加 8-10 字节可能会增加您的项目大小并将其推入下一个成本范围。例如，如果您有一个 1040 字节的项目，并且添加了 10 个字节，则您的项目大小将从每次更新收取 1WCU 增加到 2WCU，从而使写入成本增加一倍。再说一次，虽然微不足道，但需要注意。
但正如我一开始所说，没有真正的缺点。