在 DynamoDB 中製作關聯式資料模型的最佳實務 - Amazon DynamoDB
傳統關聯式資料庫模型DynamoDB 如何消除對操作的需求 JOINDynamoDB 交易如何消除寫入程序的負荷

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

在 DynamoDB 中製作關聯式資料模型的最佳實務

本節提供在 Amazon DynamoDB 中建構關聯式資料模型的最佳實務。首先，我們要介紹傳統的資料模型建構概念。然後，我們說明使用 DynamoDB 相較於JOIN傳統關聯式資料庫管理系統的優點 — 如何消除操作需求並減少額外負荷。

然後我們將說明如何設計可有效擴展的 DynamoDB 資料表。最後我們會提供一個範例來說明，如何在 DynamoDB 中建模關聯式資料的模型。

主題

傳統關聯式資料庫模型

傳統的關係數據庫管理系統（RDBMS）將數據存儲在規範化的關係結構中。關聯式資料模型的目標是減少資料的重複 (透過標準化)，以支援參考完整性並減少資料異常。

下列結構描述是一般訂單輸入應用程式的關聯式資料模型範例。此應用程式支援人力資源結構描述，並用它來為虛擬製造商的營運和業務支援系統提供支援。

範例RDBMS結構描述。

由於 DynamoDB 是非關聯式資料庫服務，相較於傳統關聯式資料庫管理系統，它提供了更多優勢。

DynamoDB 如何消除對操作的需求 JOIN

RDBMS使用結構查詢語言 (SQL) 將資料傳回至應用程式。由於資料模型的標準化，此類查詢通常需要使用 JOIN 運算子來合併來自一或多個資料表的資料。

例如，若要產生一份採購單料號清單，依據存貨數量排序的所有倉儲 (可以出貨各料號)，您可以針對先前的綱要發出下列SQL查詢。

SELECT * FROM Orders
  INNER JOIN Order_Items ON Orders.Order_ID = Order_Items.Order_ID
  INNER JOIN Products ON Products.Product_ID = Order_Items.Product_ID
  INNER JOIN Inventories ON Products.Product_ID = Inventories.Product_ID
  ORDER BY Quantity_on_Hand DESC

SQL這種類型的查詢可以提API供訪問數據的靈活性，但它們需要大量的處理。查詢中的每個聯結都會增加查詢的執行期複雜度，因為每個資料表的資料必須暫存，然後再組裝以傳回結果集。

可能影響執行查詢時間長短的其他因素包括資料表的大小，以及要聯結的欄是否有索引。上述查詢會在數個資料表中起始複雜查詢，接著排序結果集。

消除需求JOINs是無SQL數據建模的核心。這就是為什麼我們建置 DynamoDB 來支援 Amazon.com，以及為什麼 DynamoDB 可以在任何規模提供一致的效能。鑑於SQL查詢的運行時複雜性JOINs，RBDMS性能在規模上不是恆定的。這會隨著客戶應用程式的增長而導致效能問題。

雖然資料標準化確實會減少儲存到磁碟的資料量，但影響效能的最受限資源通常是CPU時間和網路延遲。

DynamoDB 的建置目的是消除 JOINs (並鼓勵取消資料標準化) 和最佳化資料庫架構，以便透過對項目的單一請求來完全回應應用程式查詢，將這兩種限制降到最低。這些品質讓 DynamoDB 能夠在任何規模下提供個位數的毫秒速度效能。這是因為 DynamoDB 操作的執行期複雜性對於常見存取模式來說是固定的，不會隨著資料大小而改變。

DynamoDB 交易如何消除寫入程序的負荷

另一個可能減慢速度的因素RDBMS是使用交易來寫入規範化的結構描述。如範例所示，大多數線上交易處理 (OLTP) 應用程式所使用的關聯式資料結構必須細分並分散在多個邏輯資料表中時，這些資料結構儲存在RDBMS.

因此，如果應用程式嘗試讀取正在寫入的物件，則必須使用ACID符合規範的交易架構，才能避免競爭狀況和資料完整性問題。此類交易框架與關聯式結構描述結合使用時，會大幅增加寫入程序的負荷。

DynamoDB 中的交易實作禁止使用. RDBMS DynamoDB 會以單一API呼叫的形式發出交易，並限制該單一交易中可存取的項目數，以達到此目的。長時間執行的交易可能因為交易永不關閉，所以長時間或永久鎖定資料，進而導致操作問題。

為了防止 DynamoDB 中發生此類問題，交易是透過兩個不同的作業來實API作：TransactWriteItems和. TransactGetItems 這些API操作沒有開始和結束語義是在RDBMS. 此外，DynamoDB 在交易中有 100 個項目的存取限制，同樣是為了防止交易長時間執行。若要進一步了解 DynamoDB 交易，請參閱使用交易。

基於這些原因，當您的企業需要對高流量查詢進行低延遲回應時，利用 No SQL 系統通常會讓技術和經濟上有意義。Amazon DynamoDB 可避免這些問題，協助解決限制關聯式系統可擴展性的問題。

由於以下原因，通常的性能RDBMS不能很好地擴展：

  • 因此會使用昂貴的聯結來重新組合必要的查詢結果檢視。

  • 資料庫將資料標準化並存放在多個資料表中，這些資料表需要多個查詢來寫入至磁碟中。

  • 它通常會產生ACID符合標準的交易系統的效能成本。

DynamoDB 順利擴展的原因為下：

  • 結構描述靈活性可讓 DynamoDB 在單一項目中存放複雜階層資料。

  • 複合索引鍵設計可讓您將相關的項目存放在相同資料表的鄰近位置。

  • 交易以單一操作形式執行。可存取的項目數限制為 100 個，以避免操作長時間執行。

對資料存放的查詢變得簡單多了，通常是使用以下格式：

SELECT * FROM Table_X WHERE Attribute_Y = "somevalue"

與前面範例RDBMS中的相比，DynamoDB 傳回要求的資料所做的工作要少得多。