DynamoDB 复合键与二级索引

Question

我正在研究 DynamoDB，我想我了解复合键（分区键 + 排序键）和二级索引的核心概念。

现在，我对一个相当简单的案例的设计最佳实践感到好奇。

假设我有 5000 万本书，它们具有唯一的图书 ID 和作者 ID（加上其他字段）：

{
  "book_id": "ghjk-5678-kj78-98kl",
  "author_id": 1234567,
  "release_date": "1970-01-01",
  "genre": "Fiction"
}

我只曾经有这两个用例：

• 通过

  book_id

  查找书籍（每天2000万次）
• 查找

  author_id

  的所有书籍（每周一次）

我不想想要通过任何其他属性查找书籍。

“更好”的方法是什么（以及为什么）？

1. 使用复合键 (

   author_id

   +

   book_id

   )
2. 将单属性键 (

   book_id

   ) 与

   author_id

上的二级索引结合使用
3. 停止过度思考 - 这是不成熟的优化

Answer 1

我的方法是结合使用单属性键 (book_id) 和author_id 上的二级索引。

单属性键（book_id）

主要查找：对于您每天 2000 万次的用例，通过 book_id 查找一本书，单属性键非常高效。 DynamoDB 数据库（以及大多数其他数据库）针对主键查找进行了优化。

简单：无需构建复合键或管理它们带来的额外复杂性。

性能：虽然二级索引通常比主键查找慢，但它们仍然是高度优化的。鉴于这种情况并不常见，我会接受这个。

为什么不是复合键（author_id + book_id）？

效率低下：对于您的主要用例（通过 book_id 查找书籍），复合键的效率低于单属性键。

Answer 2

• 使用复合键 (

  author_id

  +

  book_id

  )

这取决于，当您找到

authorId

的书时，如果您知道这本书的

bookId

，那么是的，那就很有意义了。

• 将单属性键 (

  book_id

  ) 与

  author_id

上的二级索引结合使用

如果你在搜索书籍时不知道

authorId

，那么这是一个不错的选择。

• 停止过度思考 - 这是不成熟的优化

这是一项重大优化，现在是做出决定的时候了。

PK	SK	数据
作者1	书1	一些信息
作者1	书2	一些信息
作者1	书3	一些信息
作者4	书1	一些信息
作者2	书1	一些信息
作者2	书2	一些信息

通过这个模型，你不仅可以通过

bookId

得到一本书（只要你知道

authorId

，你还可以得到与某个作者相关的所有书籍。

在这种情况下您可能不需要索引。但如果您不知道最频繁请求的

authorId

，您的基表应该是

bookId

作为 PK，您的索引将如上所示。