本文可協助軟體開發人員和資料庫管理員，將現有的 Aerospike 應用程式遷移至以 Bigtable 做為資料庫的環境。本文會運用您對 Aerospike 的瞭解，說明遷移至 Bigtable 前必須掌握的概念。
為協助您開始使用 Bigtable 和 Aerospike，本文將：
- 比較 Aerospike 和 Bigtable 的術語。
- 提供 Bigtable 作業的總覽，並說明 Bigtable 中的資料版面配置。
- 說明資料模型和重要設計考量。
- 說明複製作業的完成方式和影響。
如要瞭解遷移程序和可用於完成遷移作業的開放原始碼工具，請參閱「從 Aerospike 遷移至 Bigtable」。
術語比較
Aerospike 和 Bigtable 都是分散式 NoSQL 資料庫，但在設計、運作和術語方面有顯著差異。
在 Aerospike 中，資料會儲存在記錄中。每筆記錄都包含一或多個具名容器，以及記錄大小 (以位元組為單位)、存留時間 (TTL) 和上次更新時間 (LUT) 等中繼資料。
Bigtable 會將資料儲存在可擴充的資料表中，每個資料表都是經過排序的鍵/值對應關係。資料表由依資料列鍵建立索引的資料列，以及由資料欄限定符識別的資料欄組成。如果資料欄彼此相關，可以形成資料欄系列。這個結構可讓您在相同鍵底下儲存多個值版本。每個版本都有專屬時間戳記，您可以在讀取作業期間篩選較早的版本，也可以根據設定的政策，透過垃圾收集功能移除這些版本。
詳情請參閱 Bigtable 儲存模型。
下表列出並說明共用概念，以及各產品使用的對應術語：
| Aerospike | Bigtable |
|---|---|
| 沒有直接對應的項目。 | 執行個體：不同 Google Cloud 區域或地區的叢集代管群組，這些叢集之間會進行複製和連線路由。 |
| 叢集：由節點集合組成的 Aerospike 部署作業。 | 叢集：位於相同地理區域的一組節點。 Google Cloud |
| 節點：提供運算資源並擁有儲存空間的伺服器。 | 節點：僅提供運算的伺服器。儲存空間由 Colossus 處理，這是獨立的分散式檔案系統。 |
| 命名空間：儲存存留時間或儲存類型等參數。在命名空間中，資料會細分為資料集和記錄。 | table：最接近 Aerospike 命名空間的項目。部分參數是在叢集層級為所有資料表設定。您可以在資料表或資料欄系列層級進行更精細的控制。 |
| set：用於記錄和參數的邏輯劃分，例如存留時間和上限大小。索引鍵在集合中不得重複。 | 沒有直接對應的項目。 |
| 沒有直接對應的項目。 | 資料表：執行個體層級的資源，會自動複寫到每個叢集。資料表包含一組由不重複的資料列鍵識別的值。資料表是稀疏的，也就是說，系統不會使用額外空間儲存不含任何值的資料欄。 |
| 沒有直接對應的項目。 | 平板電腦：連續儲存的一系列資料列。Bigtable 會將子表指派給節點，藉此達到負載平衡。平板電腦的邊界是動態的，可能會隨著時間分割或合併。 |
| 記錄：用來儲存資料的一組具名容器。大小上限為 8 MB。 | 資料列：由資料欄系列、資料欄限定詞和時間戳記識別的一組值。所有作業在資料列層級均為不可部分完成。 |
| 沒有直接對應的項目。 | 資料欄系列：按字母順序排序的資料欄群組。垃圾收集是在這個層級設定。 |
| bin：鍵/值組合，其中 bin 名稱是記錄中值的 ID。 | 資料欄限定符：儲存在資料表中的值標籤。 |
| 沒有直接對應的項目。 | 儲存格：儲存在資料表中的時間戳記值標籤。 |
| (記錄) 摘要：識別記錄的三元組雜湊值：命名空間、集合和鍵。 | 沒有直接對應的項目。 |
| key：一組內不重複的記錄 ID。 | 資料列鍵：資料列 ID，在資料表中為唯一。 |
| AQL：指令列工具，可瀏覽資料及開發 Aerospike 資料庫的使用者定義函式。 | GoogleSQL：多項 Google Cloud 服務使用的查詢語言，包括 Spanner、BigQuery 和 Bigtable。 |
資料類型限制
下表比較 Aerospike 和 Bigtable 使用的資料類型限制：
| Aerospike | Bigtable |
|---|---|
| 命名空間： Enterprise 版最多可有 32 個命名空間。 | 資料表：每個執行個體最多可有 1,000 個資料表。表格名稱不得超過 50 個字元。 |
| 設定：一個叢集最多可有 4,095 個設定。名稱長度不得超過 63 個位元組。 | 沒有直接對應的項目。 |
| 錄音：錄音大小上限為 8 MB。 | 資料列：資料列大小上限為 256 MB。 |
| 沒有直接對應的項目。 | 資料欄系列：資料欄系列數量沒有上限，但超過 100 個可能會導致效能降低。 |
| bin：容器數量不限，但每個容器最多只能保存 1 MB 的資料。垃圾桶名稱不得超過 15 個位元組。 | 欄位限定符：上限為 100 MB，但建議不要超過 10 MB。欄數沒有限制。 |
| 鍵：鍵的大小上限為 8 KB。 | 資料列鍵：資料列鍵大小上限為 4 KB。 |
如要進一步瞭解 Bigtable 和 Aerospike 的限制，請分別參閱「配額與限制」和「Aerospike 系統限制和門檻」。
架構
以下各節將概述 Bigtable 和 Aerospike 的架構。
Bigtable
Bigtable 節點與儲存層分開，因此節點不會影響資料耐久性。Bigtable 資料表用戶端不會知道基礎資料的分布情形。額外的路由層會將要求分配至正確的節點。每個節點會處理叢集的部分要求。Bigtable 資料表會分割成連續資料列所組成的區塊，稱為「子表」，並儲存在 Colossus 上。Colossus 是一種分散式檔案系統，可提供高耐用性。每個子表會與特定 Bigtable 節點相關聯。
Bigtable 的架構具備下列優點：
- Bigtable 用戶端不需要瞭解資料分配和負載平衡。這些複雜性由路由層處理。
- 由於節點之間不會複製實際資料，因此重新平衡的速度非常快，且能快速從故障中復原。
- Bigtable 節點發生故障時，資料不會遺失。
Aerospike
與 Bigtable 不同，Aerospike 的儲存空間位於提供服務的節點上。Aerospike 叢集中的每個節點 (伺服器) 都相同。系統會對記錄名稱進行雜湊處理，將每個命名空間中的資料劃分為 4,096 個分區。這些分割區會平均分配給各個節點。
節點會互相感知，並在叢集變更時重新平衡儲存的分割區。每次叢集變更時，副本都會選取主要副本，以協調重新平衡作業。用戶端程式庫應追蹤哪個備用資源儲存主要分割區，並將寫入要求傳送至正確的備用資源。如果用戶端將要求傳送至錯誤的節點 (這可能發生在重新平衡期間)，節點會重新將要求傳送至正確位置。
複製
本節會比較 Aerospike 和 Bigtable 的複製程序。
Bigtable
Bigtable 執行個體可由單一叢集或多個複製叢集組成。資料表一律會複製到執行個體中的所有叢集。在執行個體中新增或移除叢集時，對其他叢集的影響極小。
Bigtable 可在單一叢集中提供讀寫一致性。寫入作業會在單一叢集上執行，並在執行個體中的其他叢集之間保持最終一致性。與 Aerospike 不同，Bigtable 不會遺失中繼更新，因為系統會為個別儲存格建立內部版本，確保不會遺失任何寫入作業。每個叢集都會提供時間戳記最新的儲存格。
Bigtable API 提供資料表層級的一致性權杖，可用於驗證權杖建立前所做的所有變更是否已完全複製。
Aerospike
Aerospike 會在叢集內處理分區層級的複寫作業。命名空間會分割成多個分區，並平均分配到各個節點。叢集內可確保同步一致性。只有在叢集內的所有副本都確認寫入作業後，系統才會確認該作業。
您可以設定跨資料中心複製 (XDR)，在不同叢集之間同步資料。Aerospike 的資料夾會聚功能可確保複製作業完成後，所有資料中心最終都會有相同的資料，但中間的更新可能會遺失。
為確保耐久性，Aerospike 的名單式一致性演算法需要 N+1 個副本，才能處理 N 個故障。
資料模型
本節將比較 Bigtable 和 Aerospike 使用的資料模型。
彈性結構定義
Aerospike 不會強制執行結構定義限制，因此每筆記錄可以有不同的容器，且值類型各異。同樣地，Bigtable 支援稀疏資料欄，因此沒有值的資料欄不會耗用儲存空間。雖然資料欄或資料欄系列的數量沒有嚴格限制，但基於效能考量，最好將資料欄系列數量控制在 100 個以下。
資料列索引鍵設計
Bigtable 會依據資料列鍵識別資料列，資料列鍵在資料表內不得重複。這些字詞會依字典順序排序，並保留在平板電腦中。這與 Aerospike 不同，後者會根據記錄的雜湊值將記錄分配至各個節點。設計資料列鍵時，應確保經常一起存取的資料列也會一起儲存。
資料類型
Aerospike 支援進階資料類型，包括純量、GeoJSON、HyperLogLogs、清單和巢狀物件。這類資料可建立索引並查詢，且支援次要索引。此外，Aerospike 也提供伺服器端 API，可對這些資料類型執行複雜作業，例如依地理位置篩選或操控清單內容。
Bigtable API 主要用於處理原始位元組，但也有例外情況。此外，時間戳記和計數器也會原生使用 INT64，且可做為不可分割的作業遞增。查詢語言也支援許多複雜型別，例如純量、JSON 物件和 HLL 容器。未來可能會越來越多進階型別受到支援，但撰寫本文時，這類型別無法放入 Bigtable，所有內容都會在用戶端序列化。您可以使用 aerospike-migration-tools 中的轉接程式庫，將資料型別序列化。
資料欄系列
在 Bigtable 中，資料欄系列會定義資料表中要一起儲存及擷取的資料欄，且每個資料表都必須至少有一個資料欄系列。相關資料欄應歸入同一個系列。由於垃圾收集政策適用於資料欄系列層級，因此具有不同保留規定的資料應分別存放在不同的資料欄系列中。
資料欄限定詞
在 Bigtable 中，資料欄限定詞用於資料欄系列中，定義個別資料欄。表格可支援數百萬個資料欄，但最佳做法是限制單一資料列中的資料欄數量。或者，您也可以將資料欄限定符視為資料，直接在資料欄名稱中嵌入值，節省空間。
儲存格
在 Bigtable 中，儲存格是資料列鍵和資料欄名稱的交集 (資料欄系列加上資料欄限定詞)。每個儲存格都包含一或多個帶有時間戳記的值，這些值可由用戶端提供，或由服務自動套用。
次要索引
持續具體化檢視畫面可做為非同步次要索引，讓資料表能使用不同的查詢模式或屬性進行查詢。詳情請參閱「建立非同步次要索引」。
交易
Bigtable 和 Aerospike 都不支援多列交易，但單列功能有所不同。 Bigtable 可在叢集內提供完全一致的單一資料列寫入作業，並透過 mutate-row 要求支援單一資料列交易。這類交易可對單一資料列執行多項作業，且所有作業都會以不可分割的方式執行，不是全部成功就是全部失敗。此外，還有讀取-修改-寫入和檢查與變動作業，但這些作業不適用於多叢集轉送設定檔。相較之下，Aerospike 會擴充單列交易，並執行伺服器端資料操作和用戶端定義的函式。
負載平衡和容錯移轉
Aerospike 使用智慧型用戶端處理用戶端負載平衡。在用戶端執行的程序，可感知叢集狀態和資料分配情形。這個用戶端負責將要求轉送至適當的服務。
如果節點發生故障或新增節點，叢集就必須重新平衡。系統會選取暫時的主要節點，負責協調節點間的分區重新平衡和重新分配作業。在此期間，叢集仍可運作，但用戶端必須追蹤變更，才能進行要求路徑設定。如果要求傳送至錯誤的節點，系統會將要求內部轉送至正確的節點。
Bigtable 用戶端是精簡型用戶端，會向使用者隱藏叢集狀態和資料分配等所有複雜性。要求的路由作業由下一層處理，也就是 Google CloudBigtable 基礎架構內的厚實用戶端。
另一個差異是 Aerospike 不支援的轉送政策。Bigtable 會使用應用程式設定檔管理要求轉送，並透過可設定的優先順序，控管要求服務順序。轉送政策分為單一叢集和多叢集兩種。多叢集設定檔會將作業轉送至最接近的可用叢集。從作業路由器的角度來看，相同地區內的叢集距離相等。如果負責所要求鍵值範圍的節點負載過重，或暫時無法在叢集中使用，這個設定檔會提供自動容錯移轉功能。相較之下，如果叢集完全故障，Aerospike 不會提供自動容錯移轉功能。
備份與還原
Aerospike 提供名為 asbackup 和 asrestore 的外部備份和還原工具，可在用戶端建立邏輯備份，類似於執行掃描。您也可以透過 Aerospike Backup Service 或 Aerospike Kubernetes Operator 管理備份作業，這兩者都會在內部使用 asbackup 和 asrestore，並提供排程和多程序協調功能。備份並非不可分割，也就是說，備份期間發生的寫入作業可能不會擷取。
Bigtable 提供兩種方法，可滿足常見的備份需求：Bigtable 備份和受管理資料匯出。備份會建立可復原的資料表副本，並以叢集的成員物件形式儲存。您可以將備份還原為啟動備份的叢集中的新資料表。備份的目的是在應用程式層級發生毀損時建立還原點。Bigtable 備份也不是不可分割。備份副本可能已複製資料表的部分內容，而您在該部分進行了變更。
備份處理方式的主要差異
- Aerospike 備份是在用戶端建立，不需要額外的伺服器端空間，但速度較慢。在 Bigtable 中，備份會與來源資料表和資料表的其他備份共用實體儲存空間。
- Aerospike 使用者必須負責匯出、儲存及移除過時的備份資料。由於 Bigtable 備份功能已全面整合，因此 Bigtable 服務會自動處理所有這些動作。
效能注意事項
由於 Aerospike 和 Bigtable 處理讀取和寫入作業的方式不同，因此效能差異是重要的考量因素。下表列出幾個範例，說明這兩個資料庫的效能差異。詳情請參閱 Bigtable 效能指南。
| 需求考量 | Bigtable | Aerospike |
|---|---|---|
| 熱門列 | 分配平板電腦和作業，以平衡資源用量。經常存取的資料列可以隔離到單一節點的單一資料列平板電腦，限制對其他資料列的影響。 | 根據雜湊值將資料列分配到所有節點，不論流量為何。熱門資料列可能會影響整個分區的效能。 |
| 掃描已排序的鍵 | 以字典順序儲存資料，因此非常適合串流排序資料。 | 根據雜湊值分配記錄，因此掃描多個連續鍵時，需要查詢多個節點並彙整結果，速度可能會較慢。支援次要索引，包括進階類型，可減少掃描需求。 |
| 連續插入多個鍵 | 以字典順序儲存資料，也就是說，單一節點會處理許多連續的鍵寫入作業。因此，讀取或寫入模式可能會出現在負責資料列鍵空間結尾的平板電腦節點上，導致該節點過載。 | 根據雜湊值分配鍵，在寫入連續鍵時，將負載分配到多個節點。 |
| 包含大量資料欄的資料列 | 雖然 Bigtable 最多可支援 256 MB 的資料列，但處理大型資料列可能會影響效能。Bigtable 經過最佳化，可處理較小的資料列，因此在設計結構定義時，應考量儲存格的組織方式和資料存取權，避免不必要地將資料分散到多個儲存格。 | 如果遇到含有大量欄或資料桶的資料列或記錄，效能會不盡理想。 |
| 冷啟動 | 最適合經常存取的大型資料表。如果一段時間未使用後才開始傳送要求 (冷啟動)，可能會發現延遲時間較長。這是因為平板電腦的分割和節點間的分配可能不盡理想，而且快取是冷的。在冷啟動和重新平衡期間，節點之間的分配可能需要幾分鐘才能達到最佳狀態。 | 成效不會隨時間改變，因為資料分布並非以負載為依據。快取需要預熱，但索引會保留在記憶體中，因此可縮短磁碟搜尋時間，並降低快取的重要性。 |
| 許多小型資料表 | 請避免建立許多小型資料表。如果用途或結構定義不同，則有理由使用不同的資料表，但如果資料相似，則不應使用不同的資料表，因為這樣無法改善負載平衡，還會增加管理負擔。 | 大多數記錄都位於一個命名空間中，並分組為多個集合。集合沒有特定結構定義，但可以為每個集合設定次要索引或掃描作業。將資料分成多個資料集不會影響成效。 |
| 大型資料集 | 可儲存 EB 級資料集。由於採用動態平板電腦分割架構，總資料集大小不會影響效能。 | 從技術上來說，Aerospike 資料庫沒有大小限制，但 Aerospike 會分別儲存索引和記錄。這兩種資料都可以儲存在 不同類型的儲存裝置上，以提升效能。將索引儲存在 RAM 中是低延遲的必要條件，但對於非常大的資料集來說，這可能不可行。舉例來說，如果物件數量為 40 億，且複製係數為 2 (RF2)，則在 All Flash 中，與叢集內主要索引相關聯的記憶體用量為 2.5 GiB。在混合式記憶體設定中，如果主索引位於記憶體中，則會使用 476.8 GiB 的記憶體，與上述範例相同。 |
| 擴大運用 | 處理和儲存空間已分離，可獨立擴充。單一節點可處理數百 TB 甚至 PB 的資料區塊。 | 將索引儲存在 RAM 中是低延遲的必要條件。在這種情況下，機器必須與儲存空間容量一起垂直擴充，才能納入主要索引。 |
後續步驟
- 瞭解 Bigtable 結構定義設計。
- 進一步瞭解 Aerospike。
- 瞭解 Bigtable 模擬器。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的雲端架構中心。