如何使用 dynamodb 表設計來證明這些可能的需求變化（交換主鍵列）？

Question

我有以下數據結構

item_id String
version String
_id     String 
data    String

_id只是一個用於標識項目的 UUID。 目前還不需要通過該字段搜索行。

截至目前，由外部系統生成的 id item_id 是主鍵。 即給定 item_id，我希望能夠從 dynamodb 表中檢索version 、 _id和data 。

item_id -> (version, _id, data)

因此我將item_id設置為分區鍵。

對於上述“模式”的未來驗證（演變），我有兩個問題：

1. 以后如果想把version（item的版本號）合並到primary key中，是不是直接修改table，把它加成partition key就可以了？

2. 如果我還想通過_id搜索數據，是否可以修改表以將_id分配為分區鍵（這是一個唯一值，因為它是 UUID）並重新分配item_id為搜索鍵？

我想避免創建新的 dynamodb 表和數據遷移以創建新的密鑰結構，因為這可能會導致停機。

Answer 1

您無法更新 DynamoDB 中的主鍵。 從文檔：

您不能使用 UpdateItem 更新任何主鍵屬性。 相反，您需要刪除該項目，然后使用 PutItem 創建具有新屬性的新項目。

如果你想讓數據可以通過_id搜索，你可以引入一個二級索引，以_id字段作為索引的分區鍵。

例如，假設您的數據如下所示：

如果您在_id上定義了二級索引，則該索引將如下所示（與上一個示例相同的數據，只是不同的邏輯視圖）：

DynamoDB 目前沒有任何本機版本控制功能，因此您必須將其合並到您的數據中 model。幸運的是，在 web 上有很多關於此用例的討論。AWS 有 DynamoDB“最佳實踐”文檔，包括版本控制的一個例子。