本頁面由 Cloud Translation API 翻譯而成。

從 DynamoDB 遷移至 Bigtable

Bigtable 和 DynamoDB 都是分散式鍵值儲存庫，每秒可支援數百萬次查詢 (QPS)，提供可擴充至數百萬位元組的資料儲存空間，並容許節點故障。

本文適用於想要遷移至 Bigtable 的 DynamoDB 開發人員和資料庫管理員。如果您想設計應用程式，以便搭配 Bigtable 做為資料儲存區使用，這項功能也很有幫助。

如要開始使用，請使用 Google 提供的遷移工具，將資料從 DynamoDB 遷移至 Bigtable。本頁面將說明遷移工具、比較這兩個資料庫系統，並說明不同的基礎架構和互動詳細資料，這些都是遷移前必須瞭解的重要資訊。

開始使用 DynamoDB 到 Bigtable 的遷移工具

Google Cloud 專業服務提供開放原始碼遷移工具，可簡化從 DynamoDB 遷移至 Bigtable 的程序。這項工具會自動將資料匯入 Google Cloud ，然後載入 Bigtable。

使用這項工具匯出 DynamoDB 資料表，然後轉移到 Cloud Storage。這項工具會從 Cloud Storage 值區讀取匯出的檔案，並使用 Dataflow 範本轉換資料，使其與 Bigtable 相容。這項轉換包括將 DynamoDB 屬性對應至 Bigtable 列。接著，Dataflow 工作會將轉換後的資料寫入 Bigtable 資料表。

如要瞭解詳情或開始使用，請參閱「DynamoDB to Bigtable Migration Utility」。

從 DynamoDB 遷移至 Bigtable 的路徑。

比較 DynamoDB 和 Bigtable

本節將探討 DynamoDB 和 Bigtable 的相似與不同之處。

控制層

在 DynamoDB 和 Bigtable 中，控制層可讓您設定容量，以及設定和管理資源。DynamoDB 是無伺服器產品，與 DynamoDB 互動的最高層級是資料表層級。在佈建容量模式中，您可以在這裡佈建讀取和寫入要求單位、選取區域和複製功能，以及管理備份。Bigtable 並非無伺服器產品，您必須建立一或多個叢集的執行個體，而叢集的容量取決於節點數量。如要進一步瞭解這些資源，請參閱「執行個體、叢集和節點」一文。

下表比較 DynamoDB 和 Bigtable 的控制平面資源。

DynamoDB	Bigtable
資料表：具有已定義主鍵的項目集合。資料表有備份、複製和容量設定。	執行個體：一組位於不同 Google Cloud 區域或地區的 Bigtable 叢集，彼此之間會進行複寫和連線轉送。複製政策是在執行個體層級設定。叢集：位於同一地理區域的一組節點，最好與應用程式伺服器共置，以減少延遲並進行複製。Google Cloud 您可以調整每個叢集中的節點數量，藉此管理容量。表格：值的邏輯組織，以資料列鍵建立索引。備份是在資料表層級控管。
讀取容量單位 (RCU) 和寫入容量單位 (WCU)：這些單位可讓您以固定有效負載大小，每秒讀取或寫入資料。如果作業的酬載大小較大，系統會針對每項作業收取讀取或寫入單位的費用。 `UpdateItem` 作業會耗用更新項目最大大小 (更新前後) 的寫入容量，即使更新只涉及項目屬性的子集也是如此。	節點：負責讀取及寫入資料的虛擬運算資源。叢集的節點數量會影響讀取、寫入和掃描的總處理量上限。您可以根據延遲目標、要求數量和酬載大小的組合，調整節點數量。 SSD 節點的讀取和寫入輸送量相同，不像 RCU 和 WCU 之間有顯著差異。詳情請參閱「一般工作負載的效能」。
分割區：由連續資料列組成的區塊，由與節點共置的固態硬碟 (SSD) 支援。每個分區的嚴格限制為 1,000 個 WCU、3,000 個 RCU 和 10 GB 的資料。	平板電腦：由所選儲存媒體 (SSD 或 HDD) 支援的連續資料列區塊。資料表會分割成子表，以平衡工作負載。子表不會儲存在 Bigtable 的節點上，而是儲存在 Google 的分散式檔案系統中，因此在擴充時可快速重新分配資料，並透過維護多個副本來提高耐用性。
全域資料表：自動在多個區域傳播資料變更，提高資料的可用性和耐久性。	複寫：自動在多個區域或同一個區域內的多個可用區之間傳播資料變更，藉此提高資料的可用性和耐久性。
不適用 (N/A)	應用程式設定檔：設定，可指示 Bigtable 如何將用戶端 API 呼叫轉送至執行個體中的適當叢集。您也可以使用應用程式設定檔做為標記，區隔歸因指標。

地理位置複製

複製功能可用於支援客戶對下列項目的需求：

如果區域或地區發生故障，高可用性可確保業務持續運作。
將服務資料存放在靠近使用者的位置，無論使用者身在何處，都能享有低延遲服務。
需要在一組叢集上實作批次工作負載，並依賴複製功能將資料提供給服務叢集時，可使用工作負載隔離功能。

Bigtable 支援最多 8 個 Google Cloud 區域的可用區域，這些區域提供 Bigtable 服務，並支援複寫叢集。大多數區域都有三個可用區。詳情請參閱「地區和區域」。

Bigtable 會在多重主要拓撲中自動複製叢集之間的資料，因此您可以讀取及寫入任何叢集。Bigtable 複寫功能具有最終一致性。詳情請參閱「複寫總覽」。

DynamoDB 提供全域資料表，支援跨多個區域的資料表複製作業。全域資料表是多主鍵資料表，會自動跨區域複製資料。複寫模式具有最終一致性。

下表列出複寫概念，並說明這些概念在 DynamoDB 和 Bigtable 中的適用情形。

屬性	DynamoDB	Bigtable
多主資料庫複製	是。您可以讀取及寫入任何全域表格。	是。您可以讀取及寫入任何 Bigtable 叢集。
一致性模型	最終一致性。全域資料表在區域層級具備讀寫一致性。	最終一致性。只要將讀取和寫入作業傳送至同一叢集，所有資料表就能在叢集層級達到讀寫一致性。
複製延遲	不提供服務水準協議 (SLA)。秒	不提供服務水準協議。秒
設定精細程度	資料表層級。	執行個體層級。一個執行個體可以包含多個資料表。
導入	在每個所選區域中建立資料表副本，藉此建立全域資料表。區域層級。將資料表轉換為全域資料表，即可在副本之間自動複製資料。資料表必須啟用 DynamoDB Streams，且串流必須包含項目的新舊圖片。刪除區域即可移除該區域中的全域資料表。	建立包含多個叢集的執行個體。該執行個體中的叢集會自動複製資料。可用區層級。在 Bigtable 執行個體中新增及移除叢集。
複製選項	每個資料表。	每個執行個體。
流量路徑和可用性	流量會轉送至最近的地理位置副本。如果發生失敗情形，您可以套用自訂商業邏輯，判斷何時將要求重新導向至其他區域。	使用應用程式設定檔設定叢集流量轉送政策。使用多叢集轉送功能，自動將流量轉送至最接近且運作正常的叢集。如果發生故障，Bigtable 支援叢集間的自動容錯移轉，確保高可用性。
擴大運用	複製寫入要求單位 (R-WRU) 的寫入容量會在副本之間同步。複製讀取容量單位 (R-RCU) 的讀取容量是每個副本的容量。	您可以視需要從每個複寫叢集中新增或移除節點，獨立調整叢集大小。
費用	R-WRU 的費用比一般 WRU 高出 50%。	系統會針對每個叢集的節點和儲存空間收費。跨可用區的區域複製作業不會產生網路複製費用。跨區域或跨大陸複製資料時，會產生相關費用。
服務水準協議	99.999%	99.999%

資料層

下表比較 DynamoDB 和 Bigtable 的資料模型概念。表格中的每一列都說明類似功能。舉例來說，DynamoDB 中的項目類似於 Bigtable 中的資料列。

DynamoDB	Bigtable
項目：一組屬性，可透過主鍵在所有其他項目中識別。大小上限為 400 KB。	資料列：由資料列索引鍵識別的單一實體。大小上限為 256 MB。
不適用	資料欄系列：使用者指定的命名空間，用於將資料欄分組。
屬性：名稱和值的組合。屬性值可以是純量、集合或文件類型。屬性大小本身沒有明確限制。不過，由於每項商品的大小上限為 400 KB，如果商品只有一個屬性，則屬性大小上限為 400 KB，扣除屬性名稱占用的空間。	資料欄限定詞：資料欄系列中資料欄的專屬 ID。資料欄的完整 ID 表示為 column-family:column-qualifier。資料欄限定詞會按資料欄系列中的字母順序排序。資料欄限定詞的大小上限為 16 KB。儲存格：儲存格會保存特定資料列、資料欄和時間戳記的資料。儲存格包含一個值，大小上限為 100 MB。
主鍵：資料表中項目的專屬 ID。可以是分割區鍵或複合鍵。分區索引鍵：簡單的主鍵，由一個屬性組成。這會決定商品所在的實體分區。大小上限為 2 KB。排序鍵：決定分區內資料列順序的鍵。大小上限為 1 KB。複合鍵：由兩個屬性組成的主要索引鍵，即分割區鍵和排序鍵或範圍屬性。	資料列鍵：資料表中項目的專屬 ID。通常以值和分隔符號的串連表示。大小上限為 4 KB。資料欄限定詞可用於提供與 DynamoDB 排序鍵等效的行為。您可以使用串連的列鍵和欄位限定符，建構複合鍵。詳情請參閱本文件「結構定義設計」一節中的結構定義轉譯範例。
存留時間：系統會根據每個項目的時間戳記，判斷項目何時不再需要。在指定時間戳記的日期和時間之後，系統會從資料表中刪除項目，不會耗用任何寫入輸送量。	垃圾收集：系統會根據每個儲存格的時間戳記，判斷項目何時不再需要。垃圾收集會在稱為壓縮的背景程序中刪除過期項目。垃圾收集政策是在資料欄系列層級設定，可根據項目存在時間或使用者想保留的版本數量刪除項目。在調整叢集大小時，您不需要為壓縮作業預留容量。

作業

資料平面作業可讓您對資料表中的資料執行建立、讀取、更新及刪除 (CRUD) 動作。下表比較 DynamoDB 和 Bigtable 的類似資料平面作業。

DynamoDB	Bigtable
`CreateTable`	`CreateTable`
`PutItem` `BatchWriteItem`	`MutateRow` `MutateRows` Bigtable 會將寫入作業視為 upsert。
`UpdateItem` 條件式寫入遞增和遞減	`CheckAndMutateRow` `ReadModifyWriteRow` Bigtable 會將寫入作業視為 upsert。
`GetItem` `BatchGetItem`、`Query`、`Scan`	``ReadRow`` ``ReadRows`` (range、prefix、reverse scan) Bigtable 支援依資料列鍵前置字元、規則運算式模式或資料列鍵範圍 (正向或反向) 進行有效率的掃描。

資料類型

Bigtable 和 DynamoDB 都不需要結構定義。您可以在寫入時定義資料欄，不必在全資料表範圍內強制執行資料欄存在與否或資料類型。同樣地，特定資料欄或屬性資料類型可能因列或項目而異。不過，DynamoDB 和 Bigtable API 處理資料類型的方式不同。

每個 DynamoDB 寫入要求都包含各個屬性的型別定義，這些定義會與讀取要求的回應一併傳回。

Bigtable 會將所有內容視為位元組，並預期用戶端程式碼會知道類型和編碼，因此用戶端可以正確剖析回應。但遞增作業是例外狀況，因為這類作業會將值解讀為 64 位元大端序的帶正負號整數。

下表比較 DynamoDB 和 Bigtable 的資料類型差異。

DynamoDB	Bigtable
純量型別：以伺服器回應中的資料類型描述元權杖形式傳回。	位元組：位元組會在用戶端應用程式中轉換為預期類型。「遞增」會將值解讀為 64 位元大端序的帶正負號整數
集合：不含排序的獨特元素集合。	資料欄系列：您可以將資料欄限定詞做為集合成員名稱，並為每個限定詞提供單一 0 位元組做為儲存格值。集合成員會按字母順序排序，並歸入所屬的資料欄系列。
對應：未排序的鍵/值組合集合，具有不重複的鍵。	資料欄系列使用資料欄限定詞做為對應鍵，並使用儲存格值做為值。地圖鍵會依字典順序排序。
清單：經過排序的項目集合。	資料欄限定詞使用插入時間戳記可達到與 list_append 行為相同的效果，反向插入時間戳記則可達到前置效果。

結構定義設計

結構定義設計的重要考量因素是資料的儲存方式。Bigtable 和 DynamoDB 的主要差異包括下列項目的處理方式：

更新單一值
資料排序
資料版本管理
儲存大型值

更新單一值

即使更新只涉及項目屬性的子集，DynamoDB 中的 UpdateItem 作業也會耗用「之前」和「之後」項目大小中較大的寫入容量。這表示在 DynamoDB 中，您可能會將經常更新的資料欄放在不同的資料列，即使這些資料欄在邏輯上與其他資料欄屬於同一資料列也一樣。

無論是特定資料列中的唯一資料欄，還是數千個資料欄中的其中一個，Bigtable 都能同樣有效率地更新儲存格。詳情請參閱「簡單寫入」。

資料排序

DynamoDB 會雜湊處理並隨機分配分割區鍵，而 Bigtable 則會依資料列鍵以字典順序儲存資料列，並將所有雜湊處理作業交由使用者處理。

隨機金鑰分配方式不適用於所有存取模式。這項做法可降低熱門資料列範圍的風險，但如果存取模式涉及跨越分割區界線的掃描，就會變得昂貴且效率不彰。這類無界掃描很常見，特別是具有時間維度的用途。

處理這類存取模式 (跨越分割區界線的掃描) 時，DynamoDB 需要次要索引，但 Bigtable 無需次要索引即可處理。同樣地，在 DynamoDB 中，查詢和掃描作業的資料掃描量上限為 1 MB，超過此限制就必須分頁。Bigtable 沒有這類限制。

儘管分區索引鍵是隨機分配，但如果所選分區索引鍵無法平均分配流量，進而對輸送量造成負面影響，DynamoDB 仍可能出現熱分區。為解決這個問題，DynamoDB 建議採用「寫入分片」，將寫入作業隨機分散到多個邏輯分割區鍵值。

如要套用這個設計模式，您必須從固定集合 (例如 1 到 10) 建立隨機數字，然後將這個數字做為邏輯分割區鍵。由於您是隨機產生分區鍵，因此寫入資料表時，會平均分散到所有分區鍵值。

Bigtable 將這項程序稱為「索引鍵加鹽」，是避免熱子表的有效方法。

資料版本管理

每個 Bigtable 儲存格都有時間戳記，而任何指定資料欄的預設值一律是最近的時間戳記。時間戳記的常見用途是版本控管，也就是將新儲存格寫入資料欄，並以時間戳記區分該資料列和資料欄的先前版本。

DynamoDB 沒有這類概念，需要複雜的結構定義設計，才能支援版本管理。這個方法需要為每個項目建立兩個副本：一個副本的排序鍵開頭為版本號碼前置字串零，例如 v0_；另一個副本的排序鍵開頭為版本號碼前置字串一，例如 v1_。每次更新項目時，您都會在更新版本的排序鍵中使用下一個較高的版本前置字元，並將更新的內容複製到版本前置字元為零的項目中。這可確保使用零前置字元時，系統會找出任何項目的最新版本。這項策略不僅需要應用程式端邏輯來維護，還會導致資料寫入作業非常耗費資源且緩慢，因為每次寫入作業都需要讀取先前的值，外加兩次寫入作業。

多列交易與大型資料列容量

Bigtable 不支援多列交易。不過，由於它可讓您儲存比 DynamoDB 中的項目大得多的資料列，因此您通常可以設計結構定義，將相關項目歸入共用資料列鍵，藉此取得預期的交易性。如需說明此方法的範例，請參閱單一資料表設計模式。

儲存大型值

由於 DynamoDB 項目 (類似於 Bigtable 列) 的大小上限為 400 KB，因此如要儲存大型值，必須將值分割到多個項目，或儲存在 S3 等其他媒體中。這兩種方法都會增加應用程式的複雜度。相較之下，Bigtable 儲存格最多可儲存 100 MB，Bigtable 資料列則最多可支援 256 MB。

結構定義翻譯範例

本節範例會將 DynamoDB 的結構定義轉換為 Bigtable，並考量鍵結構定義設計的差異。

遷移基本結構定義

產品目錄是展示基本鍵/值模式的絕佳範例。以下是這類結構定義在 DynamoDB 中的樣貌。

主鍵		屬性
分區鍵	排序鍵	說明	價格	縮圖
帽子	fedoras#brandA	採用優質羊毛製成…	30	https://storage…
帽子	fedoras#brandB	採用耐用的抗水帆布，可承受..	28	https://storage…
帽子	newsboy#brandB	為日常造型增添復古魅力。	25	https://storage…
鞋子	sneakers#brandA	穿上…，時尚舒適兼具	40	https://storage…
鞋子	sneakers#brandB	以現代材料打造經典特色…	50	https://storage…

這個資料表從 DynamoDB 對應至 Bigtable 的程序很簡單：將 DynamoDB 的複合主鍵轉換為複合 Bigtable 資料列鍵即可。您建立一個資料欄系列 (SKU)，其中包含相同的資料欄集。

	SKU
資料列索引鍵	說明	價格	縮圖
hats#fedoras#brandA	採用優質羊毛製成…	30	https://storage…
hats#fedoras#brandB	採用耐用的抗水帆布，可承受..	28	https://storage…
hats#newsboy#brandB	為日常造型增添復古魅力。	25	https://storage…
shoes#sneakers#brandA	穿上…，時尚舒適兼具	40	https://storage…
shoes#sneakers#brandB	以現代材料打造經典特色…	50	https://storage…

單一資料表設計模式

單一資料表設計模式會將關聯式資料庫中的多個資料表，整合到 DynamoDB 的單一資料表中。您可以採用上一個範例中的方法，在 Bigtable 中完全複製這個結構定義。不過，最好在過程中解決結構化資料的問題。

在這個結構中，分割區鍵包含影片的專屬 ID，有助於將與該影片相關的所有屬性放在同一位置，以便快速存取。由於 DynamoDB 的項目大小有限制，您無法在單一資料列中放入無限數量的自由文字註解。因此，系統會使用 VideoComment#reverse-timestamp 模式的排序鍵，將每個留言做為分區中的獨立資料列，並依時間順序倒序排序。

假設這部影片有 500 則留言，而擁有者想移除影片。也就是說，所有留言和影片屬性也必須一併刪除。如要在 DynamoDB 中執行這項操作，您必須掃描這個分割區中的所有鍵，然後發出多個刪除要求，逐一疊代。DynamoDB 支援多列交易，但這項刪除要求過大，無法在單一交易中完成。

主鍵		屬性
分區鍵	排序鍵	UploadDate	格式
0123	影片	2023-09-10T15:21:48	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"}
	VideoComment#98765481	內容
	VideoComment#98765481	這項功能非常實用，特效令人驚豔。
	VideoComment#86751345	內容
	VideoComment#86751345	1:05 處似乎有音訊故障。
	VideoStatsLikes	數量
	VideoStatsLikes	3
	VideoStatsViews	數量
	VideoStatsViews	156
0124	影片	2023-09-10T17:03:21	{"480": "https://storage…", "720": "https://storage…"}
	VideoComment#97531849	內容
	VideoComment#97531849	我已與所有朋友分享。
	VideoComment#87616471	內容
	VideoComment#87616471	這個風格讓我想起某位電影導演，但我想不起來是誰。
	VideoStats	ViewCount
	VideoStats	45

遷移時請修改這個結構定義，簡化程式碼，並以更快速且經濟實惠的方式提出資料要求。Bigtable 資料列的容量遠大於 DynamoDB 項目，可處理大量留言。如要處理影片獲得數百萬則留言的情況，可以設定垃圾收集政策，只保留固定數量的最新留言。

由於更新計數器時，不需要更新整列資料，因此您也不必分割計數器。您也不必使用 UploadDate 欄或計算反向時間戳記並設為排序鍵，因為 Bigtable 時間戳記會自動以反向時間順序排序留言。這項做法可大幅簡化結構定義，如果移除影片，您就能在單一要求中，以交易方式移除影片的資料列，包括所有留言。

最後，由於 Bigtable 中的資料欄是依字典順序排序，因此您可以重新命名資料欄，以便在單一讀取要求中，快速掃描影片屬性到最近 N 個留言的範圍，這是在載入影片時的理想做法。之後，當觀眾捲動畫面時，你就能逐一瀏覽其餘留言。

	屬性
資料列索引鍵	格式	喜歡次數	檢視畫面	UserComments
0123	{"480": "https://storage…", "720": "https://storage…", "1080p": "https://storage…"} @2023-09-10T15:21:48	3	156	這項功能非常實用，特效令人驚豔，@ 2023-09-10T19:01:15 1:05 處似乎有音訊問題。@ 2023-09-10T16:30:42
0124	{"480": "https://storage…", "720":"https://storage…"} @2023-09-10T17:03:21		45	這個風格讓我想起某位電影導演，但我想不起來是誰。@2023-10-12T07:08:51

鄰接清單設計模式

請考慮這個設計的稍有不同的版本，DynamoDB 通常將其稱為鄰接清單設計模式。

主鍵		屬性
分區鍵	排序鍵	DateCreated	詳細資料
Invoice-0123	Invoice-0123	2023-09-10T15:21:48	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."}
	Payment-0680	2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"}
	Payment-0789	2023-09-10T15:21:31	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"}
Invoice-0124	Invoice-0124	2023-09-09T10:11:28	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."}
	Payment-0327	2023-09-09T10:11:10	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"}
	Payment-0275	2023-09-09T10:11:03	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"}

在這個資料表中，排序鍵不是以時間為準，而是以付款 ID 為準，因此您可以採用不同的寬欄模式，並在 Bigtable 中將這些 ID 設為個別資料欄，好處與先前的範例類似。

	月結單	付款
列鍵	詳細資料	0680	0789
0123	{"discount": 0.10, "sales_tax_usd":"8", "due_date":"2023-10-03.."} @ 2023-09-10T15:21:48	{"amount_usd": 120, "bill_to":"John…", "address":"123 Abc St…"} @ 2023-09-10T15:21:40	{"amount_usd": 120, "bill_to":"Jane…", "address":"13 Xyz St…"} @ 2023-09-10T15:21:31
資料列鍵	詳細資料	0275	0327
0124	{"discount": 0.20, "sales_tax_usd":"11", "due_date":"2023-10-03.."} @ 2023-09-09T10:11:28	{"amount_usd": 70, "bill_to":"Kate…", "address":"21 Zyx St…"} @ 2023-09-09T10:11:03	{"amount_usd": 180, "bill_to":"Bob…", "address":"321 Cba St…"} @ 2023-09-09T10:11:10

如先前範例所示，只要採用適當的結構定義設計，Bigtable 的寬欄模型就能發揮強大效用，並提供許多用途，這些用途在其他資料庫中需要耗費資源的多列交易、次要索引或刪除時的連鎖行為。

後續步驟

瞭解 Bigtable 結構定義設計。
瞭解 Bigtable 模擬器。
探索有關Google Cloud的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。