本文為英文版的機器翻譯版本，如內容有任何歧義或不一致之處，概以英文版為準。
如 Amazon DynamoDB 這類的 NoSQL 資料庫會使用備用模型來管理資料，例如鍵值的配對或文件儲存。當您從關聯式資料庫管理系統切換至 如 DynamoDB 這類的 NoSQL 資料庫時，請務必了解主要差異和特定設計方法。
關聯式資料設計與 NoSQL 間的差異
關聯式資料庫管理系統 (RDBMS) 和 NoSQL 資料庫各有優劣：
-
RDBMS 可以彈性地查詢資料，但查詢相對昂貴，而且在高流量的狀況下擴展不易 (請參閱 在 DynamoDB 中製作關聯式資料模型的第一步)。
-
在如 DynamoDB 這類的 NoSQL 資料庫中，可以少數方式有效地查詢資料，但在外部的查詢就非常昂貴而且速度緩慢。
這些差異讓兩種系統之間的資料庫設計不同：
-
在 RDBMS 中，您會針對靈活性而進行設計，而不需擔心實行詳細資訊或效能。查詢最佳化通常不會影響結構描述設計，但標準化相當重要。
-
在 DynamoDB 中，您會特別設計結構描述，盡可能以最快最便宜的方式進行常用與重要的查詢。系統會打造您的資料結構，以符合企業使用案例的特定要求。
NoSQL 設計的兩個主要概念
NoSQL 設計思維與 RDBMS 設計不同。針對 RDBMS，您可以直接建立標準化的資料模型，而不需考量存取模式。您可以在稍後有新問題與查詢要求時擴展此模型。您可以將每種資料整理至其資料表。
NoSQL 設計的不同之處
-
相反地，針對 DynamoDB，您不應開始設計結構描述，除非您知道其將需要回答的問題。必須事先了解企業問題和應用程式使用案例。
-
您在 DynamoDB 應用程式中維護的資料表應越少越好。擁有較少的資料表可讓事物更具擴展性，需要較少的許可管理，並減少 DynamoDB 應用程式的額外負荷。它還可以幫助降低整體備份成本。
NoSQL 設計方法
設計 DynamoDB 應用程式的第一步即是辨識系統必須滿足的特定查詢模式。
特別是，請務必了解應用程式存取模式的三種基本屬性，再開始進行：
-
資料大小：了解資料一次儲存與要求的方式，是協助判斷分割資料的最有效方法。
-
資料形狀：NoSQL 資料庫會組織資料，而非在資料處理時重新改造資料 (如 RDBMS 系統)，如此其在資料庫中的狀態就會與將受到查詢的項目相對應。此為提升速度與可擴展性的關鍵因素。
-
資料速度：DynamoDB 會隨著增加程序查詢可用的實體分割區數與有效地在這些分割區間散佈資料來擴展。事先了解尖峰查詢負載，將可能有助於判斷如何分割資料以有效使用輸入/輸出容量。
在您識別特定查詢要求後，您可以根據管理效能的一般原則來組織資料：
-
將相關的資料保持在一起。 研究已顯示，將相關資料集中在一個位置的「參考定位」原則，是改善 NoSQL 系統中效能和回應時間的關鍵因素，就像許多年前發現最佳化路由表的重要因素一樣。
作為一般規則，您在 DynamoDB 應用程式中維護的資料表應越少越好。
例外狀況包含大量時間序列資料涉及其中的案例，或存取模式極為不同的資料集。含反轉索引的單一資料表通常可以啟用簡單查詢，來建立並擷取您應用程式所需的複雜階層資料結構。
-
使用排序。 若相關項目的索引鍵設計為能一起排序，則可以一起分組，以更有效地進行查詢。此為重要的 NoSQL 設計策略。
-
發佈佇列。 也請務必不要將大量查詢集中在資料庫的某個部分，因為這些部分可能會超過 I/O 容量。反之，您應該設計資料金鑰，盡可能將流量平均分散到分割區，避免熱點。
-
使用全域次要索引。 透過建立特定全域次要索引，您可以啟用主要資料表可支援的不同查詢，這能維持速度且費用相對便宜。
這些一般原則會轉換為常見設計模式，讓您可以在 DynamoDB 使用它們來有效打造資料模型。
DynamoDB 專用 NoSQL Workbench
沒有SQL適用於 DynamoDB 的 Workbench 是跨平台用戶端 GUI 應用程式，可用於現代資料庫開發和操作。適用於 Windows、macOS 和 Linux。NoSQL Workbench 是視覺化開發工具，提供了資料模型建立、資料視覺化、範例資料產生和查詢開發功能，協助您設計、建立、查詢及管理 DynamoDB 資料表。借助 DynamoDB 專用 NoSQL Workbench，您可以使用滿足您應用程式資料存取模式的現有資料模型，來建置新的資料模型或設計模型。您也可以在程序結束時，匯入及匯出設計好的資料模型。如需詳細資訊，請參閱使用 NoSQL Workbench 建置資料模型。
