沒有SQL DynamoDB 的設計

Amazon DynamoDB 之類的資料庫系統都SQL未使用替代模型進行資料管理，例如鍵值對或文件儲存。當您從關聯式資料庫管理系統切換至無SQL資料庫系統，例如 DynamoDB 時，請務必了解主要差異和特定設計方法。

關聯式資料設計與否之間的差異SQL

關聯式資料庫系統 （RDBMS） 和沒有SQL資料庫具有不同的優缺點：

• 在 中RDBMS，可以靈活地查詢資料，但查詢相對昂貴，而且在高流量情況下無法很好地擴展 （請參閱 在 DynamoDB 中製作關聯式資料模型的第一步）。

• 在無SQL資料庫，例如 DynamoDB 中，資料可以以有限數量的方式有效率地查詢，超出這些查詢可能昂貴且緩慢。

這些差異讓兩種系統之間的資料庫設計不同：

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

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

無SQL設計的兩個關鍵概念

設計SQL不需要與RDBMS設計不同的思維模式。對於 RDBMS，您可以繼續並建立標準化資料模型，而無需考慮存取模式。您可以在稍後有新問題與查詢要求時擴展此模型。您可以將每種資料整理至其資料表。

無SQL設計有何不同

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

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

接近無SQL設計

設計 DynamoDB 應用程式的第一步即是辨識系統必須滿足的特定查詢模式。

特別是，請務必了解應用程式存取模式的三種基本屬性，再開始進行：

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

• 資料形狀 ：無SQL資料庫會整理資料，以便其在資料庫中的形狀與要查詢的內容相符，而不是在處理查詢時重新調整資料 （如同RDBMS系統）。此為提升速度與可擴展性的關鍵因素。

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

在您識別特定查詢要求後，您可以根據管理效能的一般原則來組織資料：

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

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

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

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

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

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

這些一般原則會轉換為常見設計模式，讓您可以在 DynamoDB 使用它們來有效打造資料模型。

沒有SQL DynamoDB 的 Workbench

沒有適用於 DynamoDB 的SQL工作台 是跨平台的用戶端GUI應用程式，可用於現代資料庫開發和操作。適用於 Windows、macOS 和 Linux。沒有SQL Workbench 是視覺化開發工具，可提供資料建模、資料視覺化、範例資料產生和查詢開發功能，協助您設計、建立、查詢和管理 DynamoDB 資料表。使用 NoSQL Workbench for DynamoDB ，您可以從現有資料模型中建立新的資料模型，或根據滿足應用程式資料存取模式的現有資料模型設計模型。您也可以在程序結束時，匯入及匯出設計好的資料模型。如需詳細資訊，請參閱使用 NoSQL Workbench 建置資料模型。