本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。

DynamoDB 中的資料建模建置區塊

本節介紹建置區塊層，為您提供了可在應用程式中使用的設計模式。

複合排序索引鍵建置區塊

當人們思考 NoSQL 時，他們也可能認為它是非關聯式的。最終，DynamoDB 結構描述中無法放入關係是不合理的，它們只是看起來與關聯式資料庫及其外部索引鍵不同而已。其中一項可以用來在 DynamoDB 中開發資料邏輯階層的最關鍵模式，就是複合排序索引鍵。最常見的設計模式，是以井字號將階層中的每一層 (父層 > 子層 > 孫層) 隔開。例如 PARENT#CHILD#GRANDCHILD#ETC。

雖然 DynamoDB 中的分割區索引鍵一律需要確切的值才能查詢資料，但我們可以將部分條件從左至右套用至排序索引鍵，類似於周遊二元樹。

在上面的範例中，我們有一間需要在使用者工作階段中維護購物車的電子商務商店。每當使用者登入時，他們可能希望看到整個購物車，包括儲存供日後使用的項目。但是，在他們進入結帳程序時，只應載入使用中購物車內的項目以供購買。由於這兩個 KeyConditions 都明確要求 CART 排序索引鍵，因此 DynamoDB 會在讀取時直接忽略額外的願望清單資料。雖然儲存的項目和使用中的項目都屬於同一個購物車，但我們需要在應用程式的不同部分中以不同的方式處理它們，因此在排序索引鍵的字首上套用 KeyCondition，是僅擷取應用程式每個部分所需資料的最佳方式。

此建置區塊的主要特徵

多租用建置區塊

許多客戶使用 DynamoDB 來託管多租戶應用程式的資料。針對這些案例，我們想要設計結構描述，以便將單一租戶的所有資料保留在其本身的資料表邏輯分割區中。這會利用「項目集合」的概念，該術語是指 DynamoDB 資料表中具有相同分割區索引鍵的所有項目。如需 DynamoDB 如何處理多租戶的詳細資訊，請參閱 Multitenancy on DynamoDB。

在此範例中，我們正在執行一個可能有成千上萬使用者的相片託管網站。每個使用者最初只會將相片上傳到自己的個人資料，但預設情況下，我們不允許使用者查看任何其他使用者的相片。理想情況下，應該為每個使用者呼叫 API 的授權新增額外隔離等級，以確保他們只從自己的分割請求資料，但在結構描述等級中，唯一分割區索引鍵就足夠了。

此建置區塊的主要特徵

稀鬆索引建置區塊

有時，存取模式需要尋找符合罕見項目的項目，或是接收狀態的項目 (需要提升回應)。我們不會定期查詢這些項目的整個資料集，而是可以利用全域次要索引 (GSI) 稀疏的載入資料的事實。這表示只有基礎資料表中具有在索引中定義之屬性項目，才會複寫至索引。

在此範例中，我們可看到 IOT 使用案例，在欄位中的每個裝置都會定期回報狀態。對於大多數報告，我們期望裝置會報告一切正常，但有時可能會出現故障，必須提升給維修技術人員處理。對於具有升級的報告而言，系統會新增該項目的屬性 EscalatedTo，但不會顯示該屬性。本範例中的 GSI 由 EscalatedTo 分割，由於 GSI 會從基礎資料表中引入金鑰，我們仍然可以看到哪個 DeviceID 報告了故障以及何時報告故障。

雖然在 DynamoDB 中的讀取成本比寫入低，但稀疏索引是非常強大的工具，適用於特定類型項目的執行個體罕見，但讀取以找到它們卻很常見的使用案例。

此建置區塊的主要特徵

建置區塊生存時間

大多數資料都有一定的持續時間，可以視為值得保存在主要資料儲存中。為了協助在 DynamoDB 中的資料老化，它具有稱作存留時間 (TTL) 的功能。TTL 功能可讓您在資料表層級定義特定屬性，這些屬性需要監視具有 epoch 時間戳記 (已為過去的事) 的項目。這使您可以免費從資料表中刪除過期記錄。

在此範例中，我們有一個應用程式專門設計用來讓使用者建立短期訊息。在 DynamoDB 中建立訊息時，應用程式的程式碼會將 TTL 屬性設定為未來七天的日期。在大約七天內，DynamoDB 會看到這些項目的 epoch 時間戳記已經過去，並將其刪除。

由於 TTL 完成的刪除是免費的，因此強烈建議您使用此功能從資料表中移除歷史資料。這將減少每個月的整體儲存體費用，並可能降低使用者讀取成本，因為他們查詢擷取的資料將較少。雖然 TTL 是在資料表層級啟用的，但要為哪些項目或實體建立 TTL 屬性，以及將 epoch 時間戳記設定為未來多久時間，將由您決定。

此建置區塊的主要特徵

封存建置區塊生存時間

雖然 TTL 是從 DynamoDB 刪除舊資料的有效工具，但許多使用案例都需要將資料封存的保存時間比主要資料儲存更長。在此情況下，我們可以利用 TTL 對記錄的定時刪除，將過期的記錄推送到長期資料儲存。

在 DynamoDB 完成 TTL 刪除時，它仍會作為 Delete 事件推送到 DynamoDB 串流中。在 DynamoDB TTL 是執行刪除的執行者時，principal:dynamodb 的串流記錄上會有一個屬性。使用 Lambda 訂閱者到 DynamoDB Stream，我們只能為 DynamoDB 主體屬性套用事件篩選條件，並知道符合該篩選條件的任何記錄都會推送到封存存放區，例如 Amazon Glacier。

此建置區塊的主要特徵

垂直分割建置區塊

熟悉文件模型資料庫的使用者將熟悉在單一 JSON 文件中儲存所有相關資料的想法。雖然 DynamoDB 支援 JSON 資料類型，但不支援在巢狀 JSON 上執行 KeyConditions。由於 KeyConditions 會決定要從磁碟讀取多少資料，以及查詢有效消耗了多少 RCU，因此可能會導致大規模的不足。為了更最佳化 DynamoDB 的寫入和讀取，我們建議您將文件的個別實體分割為個別 DynamoDB 項目，也稱為垂直分割。

如上所示，垂直分割是實際操作中單一資料表設計的關鍵範例，但如果需要，也可以跨多個資料表進行實作。由於 DynamoDB 帳單會以 1 KB 的增量進行寫入，因此理想情況下，您應該以產生小於 1 KB 項目的方式對文件進行分割。

此建置區塊的主要特徵

寫入碎片建置區塊

DynamoDB 的極少數硬性限制之一，就是單一實體分割區每秒可維持多少輸送量 (不一定是單一分割區索引鍵) 的限制。這些限制目前是：

如果對資料表的要求超過上述任一限制，則會將錯誤傳回給 ThroughputExceededException 的用戶端 SDK，通常稱為限流。需要超過該限制的讀取操作使用案例，通常是將讀取快取放在 DynamoDB 前面，以達到最佳效果，但是寫入操作需要稱為寫入碎片的結構描述層級設計。

為了解決此問題，我們將在應用程式的 UpdateItem 代碼中的每個競爭者的分割區索引鍵結尾附加一個隨機整數。隨機整數產生器的範圍，將需要具有上限相符或超過指定競爭者每秒的寫入量除以 1000。為了支援每秒 20,000 次投票，它看起來會像 rand (0,19)。現在該資料儲存在單獨的邏輯分割區下，它必須在讀取時重新合併在一起。由於投票總數不需要是即時的，因此排定為每 X 分鐘讀取所有投票分割區的 Lambda 函式可能會偶爾為每位競爭者執行彙總，並將其寫回單一投票總記錄以供即時讀取。

此建置區塊的主要特徵