使用 DynamoDB 全域資料表的寫入模式 - Amazon DynamoDB

使用 DynamoDB 全域資料表的寫入模式

全域表在資料表永遠處於主動-主動資料表層級。不過,特別是對於 MREC 資料表,您可以透過控制寫入請求的路由方式,將其視為主動-被動配置。例如,您可以選擇將寫入請求路由至單一區域,以避免 MREC 資料表中可能發生的寫入衝突。

接下來三個章節將說明三種主要的受管寫入模式。您應該考慮哪種寫入模式適合您的使用案例。此選項會影響您的路由請求、疏散區域以及處理災難復原的方式。後續章節中的建議取決於應用程式所採用的寫入模式。

寫入任何區域模式 (無優先層級)

下圖所示的寫入任何區域模式採完全主動-主動架構,對寫入位置不施加任何限制。任何區域隨時可以接受寫入。這是最簡單的模式,但僅適用於特定類型的應用程式。此模式適用於所有 MRSC 資料表。當所有寫入端皆具冪等性時,此模式亦適用於 MREC 資料表,因為可安全地重複執行,確保跨區域的並行或重複寫入操作不會衝突。例如,使用者更新其聯絡資料。這種模式也適用於冪等性的特殊情況 (一個僅能新增的資料集),其中所有寫入都是確定性主索引鍵下的唯一插入。最後,此模式也適用於在可容忍寫入衝突風險的 MREC 資料表。

用戶端寫入任何區域的運作方式圖表。

寫入任何區域模式是最直覺式的實作架構。因為任何區域都可以隨時成為寫入目標,路由會更加容易。容錯移轉較為容易,因為 MRSC 資料表中的項目始終保持同步,且任何最近的寫入都可重播至任意次要區域,次數不限。盡可能之下,您應該以此為寫入模式進行設計。

例如,多數影音串流服務會使用全域資料表來追蹤書籤、評論與觀看狀態等資訊。這些部署採用 MREC 資料表,因需在全球多地配置副本,以提供低延遲的讀寫操作。只要確保每個寫入操作皆具冪等性,這些部署即可使用寫入至任何區域模式。當每次更新 (例如設定最新時間碼、指派新的評論或設定新的觀看狀態) 皆直接更新使用者的新狀態,且項目的下一個正確值不依賴其目前值時,即符合此情況。若使用者的寫入請求偶然被路由至不同區域,則最後一次寫入將保留,其全域狀態將依最終指派結果一致化。在此模式下,讀取操作最終將達成一致性,延遲時間取決於最新的 ReplicationLatency 值。

在另一個範例中,一家金融服務公司使用全域資料表作為系統的一部分來維護每個客戶使用借記卡購買的動作記錄,以計算該客戶的現金回饋獎勵。他們希望為每位客戶保留一個 RunningBalance 項目。此寫入模式本質上非等冪,因為當交易連續進入時,系統會使用 ADD 表達式根據目前值修改餘額,其新值取決於當前值。透過使用 MRSC 資料表,他們仍可寫入任何區域,因為每個 ADD 呼叫都會對項目的最新值進行操作。

第三個範例是一家提供線上廣告投放服務的公司。該公司認為可接受低程度的資料遺失風險,以換取寫入任何區域模式帶來的設計簡化。當系統投放廣告時,僅有數毫秒可擷取足夠的中繼資料以判斷顯示哪則廣告,並記錄曝光,以避免短時間內重複播放相同廣告。他們透過全域資料表,為全球終端使用者提供低延遲的讀取與寫入操作。系統將每位使用者的所有廣告曝光記錄於單一項目中,並以持續增長的清單形式儲存。他們以單一項目取代附加至項目集合的方式,藉此在每次寫入操作中移除較舊的廣告曝光,而不需額外支付刪除操作費用。此寫入操作非冪等性;若同一使用者同時從多個區域接收廣告,可能發生某次廣告曝光寫入覆蓋另一筆記錄的情況。其風險在於使用者可能偶爾會看到重複的廣告。他們認為這樣的風險在可接受範圍內。

寫入單一區域 (單一主節點)

下圖所示的寫入單一區域模式採主動-被動架構,將所有資料表的寫入路由至單一主動區域。請注意,DynamoDB 沒有單一使用中區域的概念;DynamoDB 外部路由的應用程式會管理此功能。寫入單一區域模式適用於需避免寫入衝突的 MREC 資料表,因其可確保任一時間僅向單一區域執行寫入操作。當您需要使用條件式表達式但無法採用 MRSC,或需執行交易時,此寫入模式將特別有用。此類表達式僅在您確定操作的資料為最新時才可行,因此所有寫入請求必須傳送至擁有最新資料的單一區域。

使用 MRSC 資料表時,您可為方便起見選擇主要向單一區域進行寫入。例如,這有助於將 DynamoDB 以外的基礎設施擴建需求降至最低。寫入模式仍屬寫入任何區域,因為使用 MRSC 時,可於任何時間安全寫入任一區域,而無需進行衝突解決,也不會像 MREC 資料表那樣需選擇寫入單一區域

最終一致讀取可以移至任何複本區域,以達到較低的延遲。高度一致性讀取必須由單一主要區域處理。

如何寫入一個區域的運作方式圖表。

有時需因應區域性故障而切換作用中區域,這正是此模式的典型應用情境。部分使用者會定期切換作用中區域,例如採用「追日式」部署策略。這種方式會將作用中區域設置於使用活動最頻繁的地理位置附近 (通常為白天時區,因此得名),以達到最低延遲的讀寫操作。此外,它還有每天呼叫區域切換程式碼的附加優點,可確保在災難復原前完成充分測試。

被動區域可能僅在 DynamoDB 週邊維持一組縮減版的基礎設施,僅在成為主動區域時才會擴建。本指南不涵蓋「指示燈」與「暖待命」架構設計。如需更多資訊,請參閱災難復原 (DR) 架構第 III 部分:指示燈與暖待命

當使用全域資料表以實現低延遲的全球分散式讀取時,採用寫入單一區域模式效果極佳。例如,一家大型社群媒體公司需要在全球各區域提供相同的參考資料。該公司不常更新資料,但在更新時僅寫入單一區域,以避免潛在的寫入衝突。讀取操作始終可從任何區域執行。

另一個例子是前文提及的金融服務公司,該公司實作了每日現金回饋計算。該公司使用寫入任何區域模式計算餘額,而使用寫入單一區域模式追蹤現金回饋付款。這項作業需要交易功能,而 MRSC 資料表不支援此功能,因此使用獨立的 MREC 資料表並採用寫入單一區域模式會更合適。

混合主要層級 (寫入您的區域)

寫入您的區域模式 (如下圖所示) 適用於 MREC 資料表。系統會將不同資料子集分配至各自的主區域,並僅允許透過該主區域執行寫入操作。此模式屬主動-被動架構,但會依據項目決定作用中區域。每個區域皆為其專屬的非重疊資料集之主要區域,且必須限制寫入以確保正確的區域性。

此模式類似於寫入單一區域模式,但可提供更低延遲的寫入操作,因為每位使用者的資料可部署於距離其更近的網路環境中。此模式也能在各區域間更均勻地分配周邊基礎設施,並在容錯移轉情境中減少額外建置工作,因為所有區域均已有部分基礎設施處於運行狀態。

用戶端如何在單一區域中寫入每個項目的運作方式圖表。

您可以透過多種方式判定項目的主區域:

  • 內部:資料的特定屬性 (例如特殊屬性或內嵌於分割區鍵中的值) 可明確指出其主區域。此技術於使用區域固定功能為 Amazon DynamoDB 全域資料表項目設定主區域一文中說明。

  • 協商:每個資料集的主區域會透過外部機制協商決定,例如由獨立的全域服務維護指派關係。指派可能是一個有限的持續時間,之後需要重新協商。

  • 資料表導向:並非建立單一可複寫的全域資料表,而是根據複寫區域的數量建立相同數量的全域資料表。每個資料表的名稱都表示其主區域。標準操作中,所有資料都會寫入主區域,而其他區域則保留唯讀副本。在容錯移轉期間,另一個區域會暫時接管該資料表的寫入職能。

例如,假設您任職於一家遊戲公司。您需要為全球所有遊戲玩家提供低延遲的讀寫操作。您會將每位玩家指派至距離他最近的區域。該區域負責該玩家的所有讀寫操作,確保具備強一致的寫入後讀一致性。不過,若玩家外出旅行或其主區域發生中斷,替代區域中仍可使用其完整資料副本,並可重新指派新的主區域。

再舉一例,假設您任職於一家視訊會議公司。每場會議通話的中繼資料會被指派至特定區域。通話者可使用距離最近的區域,以獲得最低的通訊延遲。若發生區域中斷,透過全域資料表可迅速復原,系統能將通話處理移轉至已存在資料複本的其他區域。

摘要
  • 寫入任何區域模式適用於 MRSC 資料表,以及對 MREC 資料表的等冪呼叫。

  • 寫入單一區域模式適用於對 MREC 資料表的非等冪呼叫。

  • 寫入您的區域模式適用於對 MREC 資料表的非等冪呼叫,並適用於需確保用戶端能寫入距離最近區域的情境。