資料建模是設計應用程式如何將資料存放在指定資料庫中的程序。資料建模使用 NoSQL 資料庫 (如 DynamoDB)，與使用關聯式資料庫建模的程序不同。關聯式資料庫的建置旨在彈性，非常適合分析應用程式。在關聯式資料建模中，先從您的實體開始。具有標準化關聯式模型時，您可以滿足您的應用程式中所需的任何查詢模式。
NoSQL (非關聯式) 資料庫的設計旨在速度和規模，而不是彈性。雖然關聯式資料庫的效能可能隨著您向上擴展而降級，但是水平擴展資料庫 (如 DynamoDB) 在任何規模都提供了一致的效能。一些 DynamoDB 使用者的資料表大於 100 TB，其資料表的讀取和寫入效能與資料表大小小於 1 GB 時的效能相同。
若要使用 NoSQL 資料庫 (如 DynamoDB) 取得最佳結果，需要轉變典型關聯式資料庫的想法。在透過 DynamoDB 對資料建模時，使用以下最佳實務。
1.專注於存取模式
執行任何類型的資料建模時，先從實體關係圖開始，以說明應用程式中的不同物件 (或實體) 以及它們的連接方式 (或您的實體之間的關係)。
在關聯式資料庫中，將您的實體直接放到資料表中，並使用外部索引鍵指定關係。在您定義資料表後，關聯式資料庫會提供彈性查詢語言，從而以您所需的形狀傳回資料。
在 DynamoDB 中，在對您的資料表建模之前思考存取模式。NoSQL 資料庫專注於速度，而不是彈性。先了解您存取資料的方式，然後以將存取資料的形狀對資料建模。
在設計您的 DynamoDB 資料表之前，記錄您用於在應用程式中讀取和寫入資料的所有需求。請仔細想想應用程式中的所有流程，因為您要根據存取模式最佳化您的資料表。
2.最佳化對 DynamoDB 的請求數
在記錄您應用程式的存取模式需求後，您已準備好設計您的資料表。您應設計您的資料表，根據每個存取模式最大限度地減少對 DynamoDB 的請求數。理想情況下，每個存取模式僅需要對 DynamoDB 請求一次，因為網路請求較慢，這限制了您將在應用程式中提出的網路請求數。
若要最佳化對 DynamoDB 的請求數，您需要了解一些核心概念：
3.不要假裝關聯式模型
DynamoDB 的新手往往會嘗試在非關聯式 DynamoDB 上實作關聯式模型。如果您嘗試這樣做，會失去 DynamoDB 的大部分優勢。
人們使用 DynamoDB 嘗試的最常見反面模式 (重複出現的問題的無效回應)：
- 標準化：在關聯式資料庫中，您標準化您的資料來減少資料冗餘和儲存空間，然後使用聯結來合併多個不同的資料表。但是，大規模聯結比較慢且昂貴。DynamoDB 不允許聯結，因為其速度會隨著資料表的增長而變慢。
- 每個表格一種資料類型：您的 DynamoDB 資料表通常會將不同類型的資料包括在單一表格中。在我們的範例中，我們將 User、Game 和 UserGameMapping 實體放在單一資料表中。在關聯式資料庫中，會將它作為三個不同的資料表進行建模。
- 太多次要索引：人們通常嘗試為所需的每個額外存取模式建立次要索引。DynamoDB 無結構描述，這亦適用於您的索引。在您的屬性中使用此彈性，以跨您資料表中的多個資料類型重複使用單一次要索引。這稱為索引過載。
在下面的步驟中，我們將建置實體關係圖並預先制定存取模式。使用 DynamoDB 時，這些操作應始終是首要步驟。然後，在接下來的單元中，我們在資料表設計中實作這些存取模式。
完成單元的時間：20 分鐘
-
步驟 1：建置您的實體關係圖
任何資料建模練習的第一步是建置一個圖表，以顯示您的應用程式中的實體以及它們如何彼此相關。
在我們的應用程式中，我們具有以下實體：
• User
• Game
• UserGameMappingUser 實體表示我們應用程式中的使用者。使用者可以建立多個 Game 實體，遊戲的建立者將確定遊玩的地圖和遊戲開始的時間。User 可以建立多個 Game 實體，因此在 User 和 Game 之間存在一對多關係。
最終，Game 包含多個 User，User 可以在一段時間內於多個不同的 Game 中玩。因此，在 User 與 Game 之間存在多對多關係。我們可以使用 UserGameMapping 實體表示此關係。
請記住這些實體和關係，我們的實體關係圖如下所示。
(按一下以放大)
-
步驟 2：考量使用者設定檔存取模式
我們的遊戲的使用者需要建立使用者設定檔。這些設定檔包括使用者名稱、虛擬人物、遊戲統計資料及每位使用者的其他資訊之類的資料。使用者登入時，遊戲會顯示這些使用者設定檔。其他使用者可以檢視使用者的設定檔以審閱其遊戲統計資料及其他詳細資訊。
在使用者玩遊戲時，遊戲統計資料會更新以反映使用者玩過的遊戲數、使用者贏了的遊戲數以及使用者擊毀目標數。
根據此資訊，我們具有以下三種存取模式：
- 建立使用者設定檔 (寫入)
- 更新使用者檔案 (寫入)
- 取得使用者設定檔 (讀取)
-
步驟 3：考量遊戲前存取模式
我們的遊戲是大逃殺遊戲。玩家可以在特定地圖上建立遊戲，其他玩家可以加入遊戲。在 50 個玩家加入遊戲時，遊戲將開始，其他玩家不能加入。
在搜尋遊戲以加入時，一些玩家可能希望遊玩特定地圖。其他玩家並不關心地圖，只想跨所有地圖瀏覽開放式遊戲。
根據此資訊，我們具有以下七種存取模式：
- 建立遊戲 (寫入)
- 尋找開放式遊戲 (讀取)
- 透過地圖尋找開放式遊戲 (讀取)
- 檢視遊戲 (讀取)
- 檢視遊戲中的使用者 (讀取)
- 將使用者加入遊戲 (寫入)
- 開始遊戲 (寫入)
-
步驟 4：遊戲內和遊戲後存取模式
最後，讓我們考量遊戲期間和遊戲後的存取模式。
在遊戲期間，玩家嘗試擊敗其他玩家，成為最後玩家的目標。我們的應用程式會追蹤每個玩家在遊戲期間的殺敵數以及玩家在遊戲中生存的時間。如果某個玩家是遊戲中的最後三個幸存者之一，該玩家會獲得遊戲的金牌、銀牌或銅牌。
稍後，玩家可能要審閱自己或其他玩家玩過的遊戲。
根據此資訊，我們具有以下三種存取模式：
- 更新使用者的遊戲 (寫入)
- 更新遊戲 (寫入)
- 尋找使用者玩過的所有遊戲 (讀取)
現在我們已對應遊戲的所有存取模式。在接下來的單元中，我們使用 DynamoDB 實作這些存取模式。
請注意，規劃階段可能會重複幾次。開始是您的應用程式所需的存取模式的總體思路。對應您的資料表中的主索引鍵、次要索引和屬性。回到開頭，並確保對您的所有存取模式都感到滿意。當您有信心完成規劃階段時，繼續實作。
