让多个 GSI 在 DynamoDB 中使用相同的 PK 是否可以节省成本/效率？

Question

我有一个 DynamoDB 表，其中包含多个帖子，我希望可以按以下方式排序：

• 喜欢
• 观点
• 评论

表格看起来像这样：

PK	SK	类型	PK1	SK1	PK2	SK2	PK3	SK3
发布#1234#	发布#信息#	发帖	排序#帖子#视图#	312	排序#发布#喜欢#	005	排序#帖子#评论	132
发布#3112#	发布#信息#	发帖	排序#帖子#视图#	153	排序#发布#喜欢#	426	排序#帖子#评论	065
发布#6526#	发布#信息#	发帖	排序#帖子#视图#	525	排序#发布#喜欢#	233	排序#帖子#评论	121
用户#bob1#	用户#信息#	用户	排序#用户#好友#	012	排序#用户#上传#	012
发布#6526#	发布#详情#	帖子详情

我有 3 个 GSI（我喜欢使用通用键名，这样我就可以以不同的方式将它们重用于其他文档）。

我的 GSI 目前如下所示：

• GSI1：PK1 + SK1
• GSI2：PK2 + SK2
• GSI3：PK3 + SK3

但是 PK1、PK2 和 PK3 永远不会改变，只是因为典型约定而被使用。重用该类型与 GSI-PK 一样对我有利（而且实际上更易于人类阅读）。

我希望我的 GSI 看起来像这样：

• GSI1：类型+SK1
• GSI2：类型+SK2
• GSI3：类型+SK3

我知道我仍然需要 3 个 GSI，但我想知道这样做除了简化之外是否还有其他好处。它会以某种方式节省索引吗？是否有更好的（更多“单表设计”？）方法对按类型过滤的相同文档进行排序？

我的访问模式是：

• PK 的 1 个具体帖子
• 按顺序排序的帖子列表
  • 喜欢，
  • 评论
  • 或观点。
• PK 1 个特定用户
• 用户列表按以下顺序排序：
  • 朋友们
  • 上传

Answer 1

不，您不会节省任何成本 - 将每个 GSI 条目视为单独的自动写入。无论关键结构是什么，成本都是一样的。

您可能不想想要使用

type

作为PK，因为这会将您的数据集中到少量分区（您拥有的类型数量）。良好的 PK 具有很多价值，理想情况下分布良好 - 这就是 DynamoDB 能够扩展的原因。不幸的是，这使得 DynamoDB 对于“按视图对所有帖子进行排序”之类的事情来说是一个糟糕的选择，因为要回答这个问题，您实际上do希望所有帖子都处于同一 PK 下（这样您就可以查询它们）。因此，您不会从 DynamoDB 中获得很大的好处，并且您可能需要考虑不同的数据存储。如果您确实想使用 DynamoDB 并且拥有大量数据，您可能需要采取一些巧妙的措施，例如选择

floor(views / 100)

等分区键，将帖子存储到多个分区中。