資料建模是設計應用程式如何將資料存放在指定資料庫中的程序。資料建模使用 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 資料表通常會將不同類型的資料包括在單一表格中。在我們的範例中,我們將在單一資料表中包含使用者、朋友、相片和回應實體。在關聯式資料庫中,會將它作為四個單獨的資料表進行建模。
  • 太多次要索引:人們通常嘗試為所需的每個額外存取模式建立次要索引。DynamoDB 無結構描述,這亦適用於您的索引。在您的屬性中使用此彈性,以跨您資料表中的多個資料類型重複使用單一次要索引。這稱為索引過載

在下面的步驟中,我們將建置實體關係圖並預先制定存取模式。使用 DynamoDB 時,這些操作應始終是首要步驟。然後,在接下來的單元中,在我們的資料表設計中實作這些存取模式。

完成單元的時間︰20 分鐘


  • 步驟 1:建置您的實體關係圖

    任何資料建模練習的第一步是建置一個圖表,以顯示您的應用程式中的實體以及它們如何彼此相關。

    在我們的應用程式中,我們具有以下實體:

    • 使用者
    • 相片
    • 回應
    • 朋友關係

    使用者可以具有許多相片,而相片可以具有許多回應。最後,朋友關係實體表示使用者之間的多對多關係,因為使用者可以關注多個使用者,並且被多個其他使用者關注。

    請記住這些實體和關係,我們的實體關係圖如下所示。

    Module_2_Step_1

    (按一下以放大)

    Module_2_Step_1
  • 步驟 2:考量使用者設定檔存取模式

    現在我們有了實體關係圖,我們來考慮實體周圍的存取模式。我們從使用者開始。

    我們的行動應用程式使用者將需要建立使用者檔案。這些檔案將包括使用者名稱、檔案圖片、位置、目前狀態和對指定使用者感興趣等資訊。

    使用者將能夠瀏覽其他使用者的檔案。使用者可能想要瀏覽另一個使用者的檔案,以查看該使用者是否有興趣關注,或者只是閱讀現有朋友的一些背景資料。

    隨著時間的流逝,使用者將希望更新其檔案以顯示新狀態,或者隨著興趣的變化而更新。

    根據此資訊,我們具有以下三種存取模式:

    • 建立使用者檔案 (寫入)
    • 更新使用者檔案 (寫入)
    • 取得使用者檔案 (讀取)
       
  • 步驟 3:考量遊戲前存取模式

    現在,我們來看看圍繞相片的存取方式。

    我們的行動應用程式允許使用者上傳並與朋友共享相片,類似於 InstagramSnapchat。當使用者上傳相片時,您將需要儲存資訊,例如相片的上傳時間,以及檔案在內容傳遞網路 (CDN) 上的位置。

    當使用者不上傳相片時,他們將要瀏覽其朋友的相片。如果他們存取朋友的資料,則應該會看到該使用者的相片,其中最近的相片首先顯示。如果他們確實很喜歡相片,則可以使用四種預先定義的回應之一 (愛心、笑臉、豎起大拇指或戴墨鏡) 對相片做出「回應」。檢視相片應顯示該相片的目前回應。

    在本節中,我們具有以下存取模式:

    • 為使用者上傳相片 (寫入)
    • 檢視使用者的最新相片 (讀取)
    • 對相片做出回應 (寫入)
    • 檢視相片和回應 (讀取)
       
  • 步驟 4:遊戲內和遊戲後存取模式

    最後,我們來考慮朋友關係的存取方式。

    許多常用的行動應用程式都涉及社交網路方面。您可以關注朋友,檢視朋友活動的最新動態,以及接收有關您可能想關注的其他朋友的建議。

    在您的應用程式中,朋友關係是一種單向關係,例如 Twitter。一位使用者可以選擇關注另一位使用者,而後者也可以選擇回關注前者。對於我們的應用程式,我們將關注使用者的使用者稱為「關注者」,並將使用者關注的對象稱為「被關注者」。

    根據此資訊,我們具有以下存取模式:

    • 關注使用者 (寫入)
    • 檢視使用者的關注者 (讀取)
    • 檢視使用者關注 (讀取)

    現在,我們已經為行動應用程式對應了所有存取模式。在接下來的單元中,我們使用 DynamoDB 實作這些存取模式。

    請注意,規劃階段可能會重複幾次。開始是您的應用程式所需的存取模式的總體思路。對應您的資料表中的主索引鍵、次要索引和屬性。回到開頭,並確保對您的所有存取模式都感到滿意。您有信心完成規劃階段後,則繼續實作。