DynamoDB 的 NoSQL 設計

• RDBMS 可以彈性地查詢資料，但查詢相對昂貴，而且在高流量的狀況下擴展不易 (請參閱 在 DynamoDB 中製作關聯式資料模型的第一步)。

• 在如 DynamoDB 這類的 NoSQL 資料庫中，可以少數方式有效地查詢資料，但在外部的查詢就非常昂貴而且速度緩慢。

• 在 RDBMS 中，您會針對靈活性而進行設計，而不需擔心實行詳細資訊或效能。查詢最佳化通常不會影響結構描述設計，但標準化相當重要。

• 在 DynamoDB 中，您會特別設計結構描述，盡可能以最快最便宜的方式進行常用與重要的查詢。系統會打造您的資料結構，以符合企業使用案例的特定要求。

NoSQL 設計的不同之處

• 相反地，針對 DynamoDB，您不應開始設計結構描述，除非您知道其將需要回答的問題。必須事先了解企業問題和應用程式使用案例。

• 您在 DynamoDB 應用程式中維護的資料表應越少越好。擁有較少的資料表可讓事物更具擴展性，需要較少的許可管理，並減少 DynamoDB 應用程式的額外負荷。它還可以幫助降低整體備份成本。

• 資料大小：了解資料一次儲存與要求的方式，是協助判斷分割資料的最有效方法。

• 資料形狀：NoSQL 資料庫會組織資料，而非在資料處理時重新改造資料 (如 RDBMS 系統)，如此其在資料庫中的狀態就會與將受到查詢的項目相對應。此為提升速度與可擴展性的關鍵因素。

• 資料速度：DynamoDB 會隨著增加程序查詢可用的實體分割區數與有效地在這些分割區間散佈資料來擴展。事先了解尖峰查詢負載，將可能有助於判斷如何分割資料以有效使用輸入/輸出容量。

• 將相關的資料保持在一起。   研究已顯示，將相關資料集中在一個位置的「參考定位」原則，是改善 NoSQL 系統中效能和回應時間的關鍵因素，就像許多年前發現最佳化路由表的重要因素一樣。

  作為一般規則，您在 DynamoDB 應用程式中維護的資料表應越少越好。

  例外狀況包含大量時間序列資料涉及其中的案例，或存取模式極為不同的資料集。含反轉索引的單一資料表通常可以啟用簡單查詢，來建立並擷取您應用程式所需的複雜階層資料結構。

• 使用排序。   若相關項目的索引鍵設計為能一起排序，則可以一起分組，以更有效地進行查詢。此為重要的 NoSQL 設計策略。

• 發佈佇列。   也請務必不要將大量查詢集中在資料庫的某個部分，因為這些部分可能會超過 I/O 容量。反之，您應該設計資料金鑰，盡可能將流量平均分散到分割區，避免熱點。

• 使用全域次要索引。   透過建立特定全域次要索引，您可以啟用主要資料表可支援的不同查詢，這能維持速度且費用相對便宜。