DynamoDB 排序键的最佳实践

Question

当我专注于使用以查询为中心的方法设计 DynamoDB 时，我发现排序键变得相当冗长。

例如，我计划使用 PK，如 USER#{UUID}，结构 SK，如 ONBOARDING#{SCHOOL}#{SCHOOL_ADDRESS}#{MAJOR}#{CREATED_AT}。 我相信这种结构可以方便地按 {SCHOOL} 和 {SCHOOL_ADDRESS} 查询用户。虽然可以选择划分字段并构建 GSI，但我听说尽量减少 GSI 的使用更具成本效益。

这么长的排序键（不包括大小限制）是否存在任何潜在问题？

Answer 1

我相信这种结构可以方便地通过以下方式查询用户 {SCHOOL}，也来自 {SCHOOL_ADDRESS}。

不正确。

当您查询 DDB 时，您必须提供哈希（分区）键作为等式，然后如果您有排序键，则可以使用以下运算符之一。

• a = b — 如果属性 a 等于值 b
，则为 true
• 一个< b — true if a is less than b
• 一个<= b — true if a is less than or equal to b
• a > b — 如果 a 大于 b，则为 true
• a >= b — 如果 a 大于或等于 b，则为 true
• a BETWEEN b AND c — 如果 a 大于或等于 b 并且小于或等于 c，则为 true。

还支持以下功能：

• begins_with (a, substr) — 如果属性 a 的值以特定子字符串开头，则为 true。

注意没有

contains

。

就目前情况而言，鉴于

USER#{UUID}

基本上是唯一的（拥有超过 1 个学校/专业的用户除外），您一次只能从 DDB 表中获取一条记录的数据（除非您执行

SCAN

；不建议这样做）。

如果要查询DDB，需要选择包含1条以上记录的哈希键。

如果没有您需要的数据检索模式的示例，就很难建议一个好的散列/排序键。但除非您的设计很简单，否则您至少需要一个 GSI。可能超载了。

就您的表而言，哈希键 {SCHOOL} 和排序键 {UUID} 将允许您“按学校查询用户”。但当然，返回数据的顺序基本上是随机的。您可能最终会通过 GSI/LSI 完成所有查询。更重要的是，如果用户在同一所学校拥有多个专业，它就会崩溃。

老实说，虽然 DDB 可以代替 RDBMS，但对于许多应用程序来说，Aurora 可能是更好的选择。