NoSQL數據結構

Question

來自關系數據庫的背景，我發現有時候找到正確的方法來構造我的NoSQL數據庫是一個挑戰（是的，我意識到這聽起來很愚蠢）。 我使用DynamoDB。

如果我有3個實體-一個用戶，一個報告和一個建築物，並且許多用戶可以提交關於建築物的許多報告，那么以下結構是否可以接受？

User - index on userId
Building - index on buildingId
Report - index on reportId, userId and buildingId

還是我需要第四個表格來跟蹤用戶提交的報告？ 我的關注點是性能，吞吐量和存儲空間。

Answer 1

使用DynamoDB時， 全局二級索引提供了從表中查詢數據的替代方法。

根據您在此處描述的表，可以使用一種結構：

用戶表

• 哈希鍵：userId

建築表

• 哈希鍵：buildingId

報告表

• 哈希鍵：reportId
• ReportUser GSI
  • 哈希鍵：userId
• BuildingUser GSI
  • 哈希鍵：buildingId

以上設計的關鍵是Report表上的全局二級索引。 與主表上的哈希鍵（和可選的范圍鍵）不同，GSI上的哈希鍵（和可選的范圍鍵）不必唯一。 這意味着您可以查詢特定userId提交的所有報告，或查詢特定buildingId的所有報告。

在現實生活中，這些GSI可能希望包含范圍鍵（例如日期），以允許在查詢記錄時對記錄進行排序。

關於GSI還要記住的另一件事是，由於GSI實際上是數據的物理副本，因此您需要選擇要投影的，可以檢索的屬性。 這也意味着GSI始終是異步更新的，因此讀取始終是最終一致的。