本文適用於軟體開發人員和資料庫管理員，協助他們遷移現有應用程式，或設計新應用程式，以便與 Bigtable 搭配使用。本文會運用您對 Apache Cassandra 的知識，說明使用 Bigtable 時應瞭解的概念，如要瞭解可用來完成遷移作業的開放原始碼工具，請參閱「從 Cassandra 遷移至 Bigtable」。
Bigtable 和 Cassandra 都是分散式資料庫。這類系統會實作多維度鍵/值儲存庫，可支援每秒數萬次查詢 (QPS)、低延遲讀寫作業、可擴充至 PB 級資料的儲存空間，以及節點故障容忍度。
Bigtable 適合 Cassandra 工作負載的情況
最適合 Cassandra 工作負載的 Google Cloud 服務，取決於遷移目標和遷移後所需的 Cassandra 功能。
如果符合下列一或多項條件，Bigtable 是最佳選擇：
- 您希望使用全代管服務，不需維護期間，且具備高可用性。
- 您需要彈性調度資源，自動因應伺服器流量變化。
- 您需要讀取和寫入作業的延遲時間持續低於 10 毫秒。
- 除了 Bigtable 最佳化的純量類型外，您還使用 Cassandra 集合類型、計數器或 materialized view。
- 您有使用
USING TIMESTAMP參數的應用程式。 - 寫入輸送量和延遲時間與讀取同樣重要。
- 您採用 Cassandra 的其中一種最終一致性複製模型。
- 您的用途需要符合成本效益的儲存空間。
如要遷移應用程式，但不想變更任何程式碼，您可以選擇在 GKE 上自行管理 Cassandra，或使用 Google CloudDataStax 或 ScyllaDB 等合作夥伴的服務。如果應用程式需要大量讀取，且您願意重構程式碼，以取得關聯式資料庫功能和同步一致性，則可考慮使用 Spanner。
如果您選擇將 Cassandra 工作負載遷移至 Bigtable，本文將提供一些提示，說明重構應用程式時應考量的事項。
本文件使用方式
您不必從頭到尾閱讀這份文件，雖然本文提供這兩個資料庫的比較，但您也可以著重於適用於您用途或感興趣的主題。
為協助您比較 Bigtable 和 Cassandra，本文將：
- 比較術語，這在兩個資料庫之間可能有所不同。
- 概略說明這兩個資料庫系統。
- 瞭解各資料庫如何處理資料模型，以瞭解不同的設計考量。
- 比較資料在寫入和讀取期間的路徑。
- 檢查實體資料版面配置，瞭解資料庫架構的各個層面。
- 說明如何設定地理位置複製功能，以符合您的需求，以及如何處理叢集大小。
- 查看叢集管理、監控和安全性的詳細資料。
術語比較
雖然 Bigtable 和 Cassandra 使用的許多概念相似，但每個資料庫的命名慣例略有不同，且存在細微差異。
這兩種資料庫的核心建構區塊之一是排序字串表 (SSTable)。在這兩種架構中，系統都會建立 SSTable，以保留用於回應讀取查詢的資料。
在 2012 年的網誌文章中，Ilya Grigorik 寫道：「SSTable 是一種簡單的抽象概念，可有效儲存大量鍵/值配對，同時針對高輸送量、循序讀取或寫入工作負載進行最佳化。」
下表列出並說明共用概念，以及各產品使用的對應術語：
| Cassandra | Bigtable |
|---|---|
|
主鍵：不重複的單一或多欄位值，用於決定資料位置和排序。 分區索引鍵：單一或多欄位值，可透過一致雜湊決定資料放置位置。 分群資料欄：單一或多欄位值，可決定分區內字典編排資料的排序。 |
資料列索引鍵：單一的專屬 位元組字串，可透過字典排序決定資料的放置位置。如要模擬複合索引鍵，請使用常見的分隔符號 (例如井號「#」或百分比「%」符號)，將多個資料欄的資料合併。 |
| 節點：負責讀取及寫入與一系列主鍵分割區雜湊範圍相關聯的資料。在 Cassandra 中，資料會儲存在附加至節點伺服器的區塊層級儲存空間。 | 節點：負責讀取及寫入與一系列資料列索引鍵範圍相關聯資料的虛擬運算資源。在 Bigtable 中，資料不會與運算節點共置。而是儲存在 Google 的分散式檔案系統 Colossus 中。節點會根據作業負載和叢集中其他節點的健康狀態，暫時負責提供各種資料範圍。 |
|
資料中心：與 Bigtable 集群類似，但 Cassandra 的拓撲和複製策略可設定部分層面。 機架：資料中心內的一組節點，會影響副本放置位置。 |
叢集：位於相同地理Google Cloud 可用區的一組節點，為了延遲和複製問題而共置。 |
| 叢集：由多個資料中心組成的 Cassandra 部署作業。 | 執行個體：一組位於不同 Google Cloud 區域或區域的 Bigtable 叢集，這些叢集之間會進行複製和連線轉送。 |
| vnode：指派給特定實體節點的固定雜湊值範圍。vnode 中的資料會以一系列 SSTable 的形式，實際儲存在 Cassandra 節點上。 | 子表：SSTable，包含連續範圍內所有依字典順序排序的資料列索引鍵。子表不會儲存在 Bigtable 的節點上，而是儲存在 Colossus 的一系列 SSTable 中。 |
| 複製係數：在資料中心所有節點中維護的 vnode 副本數量。每個資料中心都會獨立設定複製因數。 | 複寫：將 Bigtable 中儲存的資料複寫到執行個體中的所有叢集。可用區叢集內的複製作業由 Colossus 儲存層處理。 |
| 資料表 (舊稱資料欄系列)：值的邏輯組織，會以不重複的主鍵建立索引。 | 資料表：值的邏輯組織，由不重複的資料列索引鍵建立索引。 |
| keyspace：邏輯資料表命名空間，定義其中資料表的複製係數。 | 不適用。Bigtable 會以透明方式處理鍵空間問題。 |
| map：Cassandra 集合類型，用於保存鍵/值組合。 | 資料欄系列：使用者指定的命名空間，可將資料欄限定詞分組，提高讀取和寫入效率。使用 SQL 查詢 Bigtable 時，資料欄系列會視為 Cassandra 的對應項。 |
| map key：用來識別 Cassandra 對應中鍵/值項目的專屬鍵 | 資料欄限定詞：資料表中儲存值的標籤，由不重複的資料列索引鍵建立索引。使用 SQL 查詢 Bigtable 時，資料欄會視為對應關係的鍵。 |
| 資料欄：儲存在資料表中的值標籤，由不重複的主鍵建立索引。 | 資料欄：資料表中儲存的值標籤，由不重複的資料列索引鍵建立索引。資料欄名稱是由資料欄系列和資料欄限定詞組合而成。 |
| 儲存格：資料表中的時間戳記值，與主鍵和資料欄的交集相關聯。 | 儲存格：資料表中的時間戳記值，與資料列索引鍵和資料欄名稱的交集相關聯。每個儲存格可儲存及擷取多個加上時間戳記的版本。 |
| counter：可遞增的欄位類型，已針對整數總和運算進行最佳化。 | 計數器：使用整數加總運算的專用資料類型儲存格。詳情請參閱「建立及更新計數器」。 |
| 負載平衡政策：在應用程式邏輯中設定的政策，用於將作業轉送至叢集中的適當節點。這項政策會考量資料中心拓撲和 vnode 權杖範圍。 | 應用程式設定檔：指示 Bigtable 如何將用戶端 API 呼叫轉送至執行個體中適當叢集的設定。您也可以使用應用程式設定檔做為標記，區隔指標。您可以在服務中設定應用程式設定檔。 |
| CQL：Cassandra 查詢語言，類似 SQL，用於建立資料表、變更結構定義、變更資料列和查詢。 | Cassandra to Bigtable client for Java 可完美取代 Cassandra 驅動程式。Java 用戶端可解讀 CQL 查詢，讓您直接將 Bigtable 與現有的 Cassandra 應用程式搭配使用，不必重寫程式碼。 Cassandra to Bigtable Proxy 轉接器是獨立層，可與應用程式平行執行，並以另一個 Cassandra 節點的形式連線至 Bigtable。Proxy 轉接器與 CQL 相容，並支援雙重寫入和大量遷移。這項功能與適用於 Java 的 Cassandra 對 Bigtable 用戶端提供的功能類似。 Bigtable API 是用於建立執行個體和叢集、建立資料表和資料欄系列、資料列突變，以及執行查詢的用戶端程式庫和 gRPC API。Bigtable SQL API 適用於 CQL 使用者。 |
materialized view：SELECT 陳述式，用於定義一組對應至基礎來源資料表中的資料列。來源資料表變更時，Cassandra 會自動更新 materialized view。 |
持續增補的 materialized view：全代管、預先運算的 SQL 查詢結果，會從來源資料表逐步自動更新。詳情請參閱「連續 materialized view」。 |
產品總覽
以下各節將概略說明 Bigtable 和 Cassandra 的設計理念和主要屬性。
Bigtable
Bigtable 提供許多核心功能，詳情請參閱「 Bigtable：適用於結構化資料的分散式儲存系統」一文。Bigtable 會將處理用戶端要求的運算節點，與基礎儲存空間管理作業分開。資料會儲存在 Colossus。儲存層會自動複製資料，提供高於標準 Hadoop 分散式檔案系統 (HDFS) 三向複製的耐用性。
這種架構可在叢集內提供一致的讀取和寫入作業、擴充及縮減資源，而不會產生任何儲存空間重新分配費用，而且可以重新平衡工作負載，而不必修改叢集或結構定義。如果任何資料處理節點發生故障，Bigtable 服務會以公開透明的方式進行更換。Bigtable 也支援非同步複製。
除了 gRPC 和各種程式設計語言的用戶端程式庫，Bigtable 也與開放原始碼 Apache HBase Java 用戶端程式庫保持相容，這是 Bigtable 論文的替代開放原始碼資料庫引擎實作方式。
下圖顯示 Bigtable 如何從儲存層實際分離處理節點：
在上圖中，中間的處理節點只負責處理儲存層中 C 資料集的資料要求。如果 Bigtable 判斷資料集需要重新平衡範圍指派作業，由於儲存層與處理層是分開的，因此處理節點的資料範圍很容易變更。
下圖以簡化方式說明鍵範圍重新平衡和叢集大小調整：
「重新平衡」圖片說明最左側的處理節點收到更多 A 資料集要求後，Bigtable 叢集的狀態。重新平衡後，中間節點 (而非最左側節點) 會負責處理 B 資料集的資料要求。最左側的節點會繼續處理 A 資料集的要求。
Bigtable 可以重新排列資料列索引鍵範圍，以便在更多可用的處理節點之間平衡資料集範圍。「Resizing」(調整大小) 圖片顯示新增節點後 Bigtable 叢集的狀態。
Cassandra
Apache Cassandra 是開放原始碼資料庫，部分受到 Bigtable 論文概念的影響。這項服務採用分散式節點架構，儲存空間與回應資料作業的伺服器位於同一位置。系統會隨機指派一系列虛擬節點 (vnode) 給每部伺服器，用於提供部分叢集鍵空間。
資料會根據分區鍵儲存在 vnode 中。通常會使用一致的雜湊函式產生權杖，以決定資料放置位置。與 Bigtable 一樣，您可以使用保留順序的分區器來產生權杖，進而用於資料放置。不過，Cassandra 說明文件不建議採用這種做法，因為叢集可能會變得不平衡，而這種情況很難補救。因此，本文件假設您使用一致的雜湊策略來產生權杖，進而將資料分配到各個節點。
Cassandra 透過與可調整一致性層級相關的可用性層級提供容錯功能，讓叢集在一或多個節點受損時為用戶端提供服務。您可以透過可設定的資料複製拓撲策略，定義地理位置複製。
您可以為每個作業指定一致性層級。一般設定為 QUORUM (或特定多資料中心拓撲中的 LOCAL_QUORUM)。這項一致性層級設定需要多數副本節點回應協調器節點，作業才會視為成功。您為每個鍵空間設定的複寫因數，會決定叢集內每個資料中心儲存的資料副本數量。舉例來說，一般會使用 3 的複寫因數值，在耐久性和儲存空間容量之間取得實用平衡。
下圖以簡化方式呈現六個節點的叢集，每個節點的金鑰範圍分為五個 vnode。在實際操作中，您可以擁有更多節點，而且可能會有更多虛擬節點。
在上圖中，您可以看到寫入作業的路徑，其一致性層級為 QUORUM，源自用戶端應用程式或服務 (「Client」(用戶端))。為方便說明，本圖顯示的鍵範圍為字母範圍。實際上，主鍵雜湊產生的權杖是非常大的帶正負號整數。
在本例中，金鑰雜湊為 M，而 M 的 vnode 位於節點 2、4 和 6。協調者必須與儲存金鑰雜湊範圍的每個節點聯絡，才能處理寫入作業。由於一致性等級為 QUORUM，因此必須有兩個副本 (多數) 回應協調器節點，用戶端才會收到寫入完成的通知。
與 Bigtable 不同，在 Cassandra 中移動或變更鍵範圍時，您必須將資料從一個節點實際複製到另一個節點。如果某個節點因特定權杖雜湊範圍的要求而超載，在 Cassandra 中為該權杖範圍新增處理作業，會比在 Bigtable 中更複雜。
地理位置複製和一致性
Bigtable 和 Cassandra 處理地理區域 (也稱為多區域) 複製和一致性的方式不同。Cassandra 叢集由處理節點組成，這些節點會分組為機架，而機架則會分組為資料中心。Cassandra 會使用您設定的網路拓撲策略，判斷 vnode 副本在資料中心主機間的分布方式。這項策略顯示 Cassandra 的根源，是最初部署在實體地端部署資料中心的資料庫。這項設定也會指定叢集中每個資料中心的複製係數。
Cassandra 會使用資料中心和機架設定，提高資料副本的容錯能力。在讀取和寫入作業期間，拓撲會決定需要哪些參與者節點，才能提供一致性保證。建立或擴充叢集時，必須手動設定節點、機架和資料中心。在雲端環境中，一般的 Cassandra 部署作業會將雲端可用區視為機架，並將雲端區域視為資料中心。
您可以運用 Cassandra 的仲裁控制項，調整每次讀取或寫入作業的一致性保證。最終一致性的強度等級可能不盡相同，包括需要單一副本節點 (ONE)、單一資料中心副本節點多數 (LOCAL_QUORUM)，或所有資料中心內多數副本節點 (QUORUM) 的選項。
在 Bigtable 中，叢集是可用區資源。Bigtable 執行個體可以包含單一叢集，也可以是一組完全複製的叢集。您可以將執行個體叢集放在 Google Cloud 提供的任何區域中，並任意組合可用區。您可以新增及移除執行個體中的叢集，對執行個體中其他叢集的影響極小。
在 Bigtable 中，寫入作業會在單一叢集上執行 (具有讀取後寫入一致性)，並最終在其他執行個體叢集中保持最終一致。由於個別儲存格會依時間戳記進行版本控管，因此不會遺失任何寫入內容，且每個叢集都會提供時間戳記最新的可用儲存格。
這項服務會公開叢集一致性狀態。Cloud Bigtable API 提供取得資料表層級一致性權杖的機制。您可以使用這個權杖，確認在權杖建立前對該資料表所做的所有變更是否已完全複製。
交易支援
雖然這兩個資料庫都不支援複雜的多列交易，但各自支援部分交易。
Cassandra 採用輕量交易 (LWT) 方法，可為單一分區中的資料欄值更新提供不可分割性。Cassandra 也提供比較和設定語意，可在寫入作業啟動前完成資料列讀取作業和值比較。
Bigtable 支援叢集內完全一致的單列寫入作業。單列交易可透過讀取-修改-寫入和檢查與變動作業進一步啟用。多叢集轉送應用程式設定檔不支援單一資料列交易。
資料模型
Bigtable 和 Cassandra 都會將資料整理成資料表，支援使用資料列的專屬 ID 進行查詢和範圍掃描。這兩個系統都歸類為 NoSQL 寬欄儲存庫。
在 Cassandra 中，您必須預先使用 CQL 建立完整資料表結構定義，包括主鍵定義，以及資料欄名稱和類型。Cassandra 的主鍵是不重複的複合值，由必要的分區鍵和選用的叢集鍵組成。分區鍵會決定資料列的節點位置，叢集鍵則會決定分區內的排列順序。建立結構定義時，您必須考量在單一分區內執行有效掃描，與維護大型分區相關系統成本之間的潛在取捨。
在 Bigtable 中，您只需要事先建立資料表並定義資料欄系列。建立資料表時不會宣告資料欄，但應用程式 API 呼叫將儲存格新增至資料表列時，就會建立資料欄。
資料列索引鍵在 Bigtable 叢集中會依字母順序排列。Bigtable 中的節點會自動平衡節點對鍵範圍的責任，通常稱為「tablet」，有時也稱為「分割」。Bigtable 資料列索引鍵通常由多個欄位值聯結而成，並使用您選擇的常用分隔符號 (例如百分比符號)。分開後，個別字串元件會類似於 Cassandra 主鍵的欄位。
資料列索引鍵設計
在 Bigtable 中，資料表資料列的專屬 ID 是資料列索引鍵。整個資料表的資料列索引鍵必須是單一不重複的值。您可以串連以通用分隔符號分隔的不同元素，建立多部分索引鍵。資料列索引鍵會決定資料表中全域資料的排列順序。Bigtable 服務會動態決定指派給各節點的鍵範圍。
與 Cassandra 不同，Bigtable 資料列索引鍵可同時提供節點指派和排序功能，而 Cassandra 的資料列放置位置是由分割區鍵雜湊決定，排序則是由叢集資料欄決定。與 Cassandra 一樣，您應在 Bigtable 中設計資料列索引鍵，以便將要一起擷取的資料列儲存在一起。不過，在 Bigtable 中，您不必先設計資料列索引鍵的放置和排序方式，就能使用資料表。
資料類型
Bigtable 服務不會強制執行用戶端傳送的資料欄資料類型。用戶端程式庫提供輔助方法，可將儲存格值寫入為位元組、UTF-8 編碼字串和大端序編碼 64 位元整數 (大端序編碼整數是原子遞增作業的必要項目)。
資料欄系列
在 Bigtable 中，資料欄系列會決定資料表中哪些資料欄會一起儲存及擷取。每個資料表至少需要一個資料欄系列，但資料表通常會有更多資料欄系列 (每個資料表最多 100 個)。應用程式必須先明確建立資料欄系列，才能在作業中使用。
資料欄限定詞
儲存在資料列鍵的每個值都會與稱為「欄位限定符」的標籤建立關聯。由於資料欄限定詞只是標籤，因此資料欄系列中的資料欄數量沒有實際限制。Bigtable 經常使用資料欄限定詞來表示應用程式資料。
儲存格
在 Bigtable 中，儲存格是資料列索引鍵和資料欄名稱 (資料欄系列與資料欄限定詞的組合) 的交集。每個儲存格都包含一或多個帶有時間戳記的值，這些值可由用戶端提供，或由服務自動套用。系統會根據在資料欄系列層級設定的垃圾回收政策，回收舊的儲存格值。
次要索引
您可以將連續 materialized view 做為資料表的非同步次要索引，使用不同的查詢模式或屬性查詢相同資料。詳情請參閱「建立非同步次要索引」。
資料模型：透過集合彈性調整
Cassandra 至 Bigtable Proxy 轉接器會將 Cassandra 集合類型 (例如對應、集合和清單) 轉換為 Bigtable 中的資料欄系列。因此，將 Bigtable 與 Cassandra 集合類型搭配使用非常有效率，因為寫入和讀取個別資料欄的速度比單一 blob 快得多。
有了 Bigtable，您就能建構包含大型動態集合的應用程式，而不必像 Cassandra 一樣犧牲效能，原因如下：
- Bigtable 會將集合元素儲存為個別儲存格，因此元素作業的精細程度很高。也就是說，單一地圖更新會轉換為輕量型儲存格寫入作業，提供高效能和高擴充性。
- 除了資料列大小限制外，Bigtable 集合沒有實際的大小限制。
- 無論集合成長到多大，Bigtable 都能維持一致的低延遲，如圖 4 所示。
相較之下，Cassandra 說明文件則建議您嚴格限制集合類型的使用，並經常將元素數量限制在較小的數量，以免效能降低。由於 Cassandra 會將集合資料欄視為整體讀取，因此大型集合必然會導致讀取延遲時間激增，並可能造成節點不穩定。
您可以透過凍結集合或將資料儲存為 JSON 字串等解決方法，繞過這些限制，但這會產生讀取-修改-寫入稅，進而犧牲效能。這項負擔會迫使資料庫在每次變更時，讀取、反序列化、更新及重寫整個物件。此外，Cassandra 會將這些 JSON blob 視為不透明文字，因此應用程式層必須具備所有剖析邏輯。這與 Bigtable 不同，Bigtable 透過 SQL API 函式提供內建的伺服器端 JSON 字串處理功能。
Bigtable 可讓您結合固定和動態結構定義元素，這可讓應用程式在重要的地方強制執行結構，同時保持靈活，讓您演進資料模型，不必進行大規模遷移或停機。此外，也支援需要頻繁疊代特徵儲存庫和全球即時服務的現代工作負載，例如機器學習和 AI。
用戶端負載平衡和容錯移轉
在 Cassandra 中，用戶端會控管要求的負載平衡。用戶端驅動程式會設定政策，該政策會在工作階段建立期間指定為設定的一部分，或以程式輔助方式設定。叢集會向政策提供最接近應用程式的資料中心資訊，用戶端則會從這些資料中心找出節點來執行作業。
Bigtable 服務會根據每個作業提供的參數 (應用程式設定檔 ID)，將 API 呼叫轉送至目的地叢集。應用程式設定檔會在 Bigtable 服務中維護；未選取設定檔的用戶端作業會使用預設設定檔。
Bigtable 有兩種應用程式設定檔路由政策：單一叢集和多叢集。多叢集設定檔會將作業轉送至最接近的可用叢集。從作業路由器的角度來看，相同區域中的叢集距離相等。如果叢集中負責所要求金鑰範圍的節點超載或暫時無法使用，這種類型的設定檔會提供自動容錯移轉功能。
就 Cassandra 而言，多叢集政策可提供負載平衡政策的容錯移轉優勢，並瞭解資料中心。
如果應用程式設定檔採用單一叢集轉送功能，所有流量都會導向單一叢集。只有具備單一叢集轉送功能的設定檔，才支援強大的資料列一致性和單一資料列交易。
單一叢集方法的缺點是，在容錯移轉時，應用程式必須能夠使用替代應用程式設定檔 ID 重試，或者您必須手動執行受影響的單一叢集轉送設定檔容錯移轉。
作業路徑
Cassandra 和 Bigtable 會使用不同的方法，選取讀取和寫入作業的處理節點。Cassandra 會識別分區鍵，Bigtable 則使用資料列索引鍵。
在 Cassandra 中，用戶端會先檢查負載平衡政策。這個用戶端物件會決定作業的路由目的地資料中心。
識別資料中心後，Cassandra 會與協調器節點聯絡，以管理作業。如果政策可辨識權杖，協調器就是從目標 vnode 分區提供資料的節點；否則，協調器就是隨機節點。協調器節點會找出作業分區鍵的資料副本所在節點，然後指示這些節點執行作業。
如前所述，在 Bigtable 中，每項作業都包含應用程式設定檔 ID。應用程式設定檔是在服務層級定義。Bigtable 轉送層會檢查設定檔，為作業選擇適當的目的地叢集。接著，轉送層會使用作業的資料列索引鍵，提供作業路徑，讓作業抵達正確的處理節點。
資料寫入程序
這兩個資料庫都經過最佳化，可快速寫入資料，且完成寫入的程序類似。不過，資料庫採取的步驟略有不同，尤其是 Cassandra，因為視作業一致性層級而定，可能需要與其他參與者節點通訊。
寫入要求路由至適當的節點 (Cassandra) 或節點 (Bigtable) 後，系統會先將寫入內容依序保留在提交記錄 (Cassandra) 或共用記錄 (Bigtable) 中。接著，寫入作業會插入記憶體內資料表 (也稱為「memtable」)，其排序方式與 SSTable 相同。
完成這兩個步驟後，節點會回覆，表示寫入作業已完成。 在 Cassandra 中，協調器會先等候多個副本回應 (取決於為每項作業指定的一致性層級)，再通知用戶端寫入作業已完成。在 Bigtable 中，由於每個資料列索引鍵在任何時間點都只會指派給單一節點，因此只要節點回應，就能確認寫入成功。
之後，如有需要，您可以將 memtable 以新 SSTable 的形式清除至磁碟。在 Cassandra 中，當修訂記錄達到大小上限，或 memtable 超過您設定的門檻時，就會進行清除。在 Bigtable 中，當 memtable 達到服務指定的最大大小時，系統會啟動排清作業，建立新的不可變動 SSTable。壓縮程序會定期將特定鍵範圍的 SSTable 合併為單一 SSTable。
資料更新
這兩個資料庫處理資料更新的方式類似。不過，Cassandra 每個儲存格只能有一個值，而 Bigtable 每個儲存格可保留大量版本化值。
當不重複資料列 ID 和資料欄交集處的值遭到修改時，系統會按照先前「資料寫入程序」一節所述的方式保留更新。寫入時間戳記會與 SSTable 結構中的值一起儲存。
如果尚未將更新後的儲存格排清至 SSTable，您只能將儲存格值儲存在記憶體資料表，但資料庫儲存的內容有所不同。Cassandra 只會將最新值儲存在 memtable 中，而 Bigtable 則會將所有版本儲存在 memtable 中。
或者，如果您已將至少一個版本的儲存格值排清至個別 SSTable 的磁碟，資料庫會以不同方式處理該資料的要求。向 Cassandra 要求儲存格時，系統只會根據時間戳記傳回最新值；換句話說，最後寫入的值會勝出。在 Bigtable 中，您可以使用篩選器，控制讀取要求傳回的儲存格版本。
刪除資料列
由於這兩個資料庫都使用不可變更的 SSTable 檔案將資料保存到磁碟，因此無法立即刪除資料列。為確保查詢在刪除資料列後傳回正確結果，這兩個資料庫會使用相同機制處理刪除作業。系統會先將標記 (在 Cassandra 中稱為「墓碑」) 新增至 memtable。最後，新寫入的 SSTable 會包含一個帶有時間戳記的標記，指出不重複的資料列 ID 已刪除，不應在查詢結果中傳回。
存留時間 (TTL)
這兩個資料庫的存留時間 (TTL) 功能類似，但有一項差異。在 Cassandra 中，您可以為資料欄或資料表設定 TTL，但在 Bigtable 中，您只能為資料欄系列設定 TTL。Bigtable 提供一種方法，可模擬儲存格層級的 TTL。
垃圾回收
如前所述，不可變更的 SSTable 無法立即更新或刪除資料，因此垃圾回收會在稱為「壓縮」的程序中進行。這個程序會移除不應在查詢結果中提供的儲存格或資料列。
發生 SSTable 合併時，垃圾收集程序會排除資料列或儲存格。如果資料列有標記或墓碑，該資料列就不會納入產生的 SSTable。這兩個資料庫都可以從合併的 SSTable 中排除儲存格。如果儲存格時間戳記超過存留時間 (TTL) 資格，資料庫就會排除該儲存格。如果特定儲存格有兩個加上時間戳記的版本，Cassandra 只會在合併的 SSTable 中納入最新值。
資料讀取路徑
當讀取作業到達適當的處理節點時，兩個資料庫取得資料以滿足查詢結果的讀取程序都相同。
針對磁碟上可能包含查詢結果的每個 SSTable，系統會檢查布隆篩選器，判斷每個檔案是否包含要傳回的資料列。由於 Bloom 篩選器絕不會提供偽陰性結果，因此所有符合資格的 SSTable 都會加入候選清單，以便納入後續的讀取結果處理程序。
讀取作業會使用合併檢視表執行，該檢視表是根據 memtable 和磁碟上的候選 SSTable 建立。由於所有鍵都依字典順序排序，因此可以有效率地取得合併檢視畫面，並透過掃描取得查詢結果。
在 Cassandra 中，一組由作業一致性層級決定的處理節點必須參與作業。在 Bigtable 中，只需要查詢負責鍵值範圍的節點。如果是 Cassandra，您需要考量運算大小的影響，因為多個節點可能會處理每次讀取作業。
處理節點會以略有不同的方式限制讀取結果。
在 Cassandra 中，CQL 查詢中的 WHERE 子句會限制傳回的資料列。限制是主鍵中的資料欄或次要索引中包含的資料欄，可用於限制結果。
Bigtable 提供多種篩選器，可影響讀取查詢擷取的資料列或儲存格。
篩選條件可分為三類：
- 限制篩選器：控制回應包含的資料列或儲存格。
- 修改篩選器，這會影響個別儲存格的資料或中繼資料。
- 組合篩選器：可將多個篩選器合併為一個。
限制篩選器是最常用的篩選器，例如資料欄系列規則運算式和資料欄限定詞規則運算式。
實體資料儲存
Bigtable 和 Cassandra 都會將資料儲存在 SSTable 中，並在壓縮階段定期合併。SSTable 資料壓縮功能也有類似的好處，可縮減儲存空間大小。不過，Bigtable 會自動套用壓縮功能，而 Cassandra 則提供壓縮設定選項。
比較這兩個資料庫時，您應瞭解各資料庫在下列方面的實體資料儲存方式有何不同：
- 資料分布策略
- 可用的儲存格版本數量
- 儲存磁碟類型
- 資料耐久性和複製機制
資料分布
在 Cassandra 中，建議使用主鍵分區欄的一致性雜湊，判斷叢集節點服務的各種 SSTable 間的資料分布情形。
Bigtable 會使用完整資料列索引鍵中的可變前置字串，將資料依字典順序放入 SSTable。
儲存格版本
Cassandra 只會保留一個有效儲存格值版本。如果對儲存格執行兩次寫入作業，最後寫入優先政策會確保只傳回一個值。
Bigtable 不會限制每個儲存格的時間戳記版本數量。可能須遵守其他資料列大小限制。如果用戶端要求未設定，時間戳記會由 Bigtable 服務在處理節點收到異動時決定。您可以透過垃圾收集政策修剪儲存格版本，每張資料表的欄系列可採用不同的政策，也可以透過 API 從查詢結果集篩選版本。
磁碟儲存空間
Cassandra 會將 SSTable 儲存在連接至各個叢集節點的磁碟上。如要在 Cassandra 中重新平衡資料，必須在伺服器之間實際複製檔案。
Bigtable 會使用 Colossus 儲存 SSTable。由於 Bigtable 使用這個分散式檔案系統，因此 Bigtable 服務幾乎可以立即將 SSTable 重新指派給不同的節點。
資料耐久性和複製
Cassandra 會透過複製因數設定，確保資料持久性。複製係數會決定儲存在叢集中不同節點上的 SSTable 副本數量。複製係數的一般設定為 3，即使發生節點故障，仍可透過 QUORUM 或 LOCAL_QUORUM 確保更強的同步一致。
Bigtable 透過 Colossus 提供的複製功能，確保資料具有高耐用性。
下圖說明 Bigtable 的實體資料版面配置、運算處理節點和轉送層：
在 Colossus 儲存層中，每個節點都會指派為提供儲存在一系列 SSTable 中的資料。這些 SSTable 包含動態指派給每個節點的資料列索引鍵範圍資料。雖然圖表顯示每個節點有三個 SSTable，但實際上可能更多，因為節點收到新的資料變更時，會持續建立 SSTable。
每個節點都有共用記錄。 寫入 由每個節點處理後，會立即保存至共用記錄，然後用戶端才會收到寫入確認訊息。由於寫入 Colossus 的資料會多次複製，因此即使節點硬體在資料保存至資料列範圍的 SSTable 之前發生故障，也能確保資料持久性。
應用程式介面
原本 Cassandra 資料庫存取權是透過 Thrift API 公開，但這種存取方法已淘汰。建議透過 CQL 進行用戶端互動。
與 Cassandra 的原始 Thrift API 類似，Bigtable 資料庫存取權是透過 API 提供，該 API 會根據提供的資料列索引鍵讀取及寫入資料。
與 Cassandra 相同，Bigtable 也有指令列介面 (稱為 cbt CLI)，以及支援多種常見程式設計語言的用戶端程式庫。這些程式庫是以 gRPC 和 REST API 為基礎建構而成。為 Hadoop 編寫且依賴 Java 適用的開放原始碼 Apache HBase 程式庫的應用程式，無須大幅變更即可連線至 Bigtable。如果應用程式不需要 HBase 相容性，建議您使用內建的 Bigtable Java 用戶端。
Bigtable 的身分與存取權管理 (IAM) 控制項與 Google Cloud完全整合，資料表也可做為 BigQuery 的外部資料來源。
資料庫設定
設定 Cassandra 叢集時，您需要做出多項設定決策，並完成多個步驟。首先，您必須設定伺服器節點，提供運算能力並佈建本機儲存空間。如果使用建議且最常見的設定，也就是複製係數為三，則必須佈建儲存空間，以儲存預期在叢集中保留的三倍資料量。您也必須判斷並設定 vnode、機架和複寫的設定。
與 Cassandra 相比，Bigtable 分開處理運算和儲存作業，因此可簡化叢集擴充和縮減作業。在正常運作的叢集中，您通常只需要考量代管資料表使用的儲存空間總量 (這會決定節點數量下限)，以及是否有足夠的節點來維持目前的 QPS。
如果叢集根據生產環境負載過度或不足佈建，您可以快速調整 Bigtable 叢集大小。
Bigtable 儲存空間
除了初始叢集的地理位置外，建立 Bigtable 執行個體時，您唯一需要選擇的是儲存空間類型。Bigtable 提供兩種儲存空間選項：固態硬碟 (SSD) 或傳統硬碟 (HDD)。執行個體中的所有叢集必須共用相同的儲存空間類型。
使用 Bigtable 時，您不需要像調整 Cassandra 叢集大小一樣，考慮儲存空間副本。與 Cassandra 不同，Spanner 不會為了容錯而犧牲儲存密度。此外，由於儲存空間不需明確佈建，因此您只需支付實際使用的儲存空間費用。
SSD
SSD 節點的容量為 5 TB，適用於大多數工作負載，與 Cassandra 機器的建議設定相比，儲存密度更高。Cassandra 機器的每個節點實際最大儲存密度不到 2 TB。評估儲存空間容量需求時，請注意 Bigtable 只會計算一份資料，相較之下，Cassandra 在大多數設定下需要計算三份資料。
雖然 SSD 的寫入 QPS 與 HDD 大致相同，但 SSD 的讀取 QPS 遠高於 HDD。SSD 儲存空間的價格與佈建的 SSD 永久磁碟成本相當或接近，且因區域而異。
HDD
HDD 儲存空間類型可提供相當高的儲存空間密度，每個節點可達 16 TB。但缺點是隨機讀取速度會明顯變慢，每個節點每秒只能讀取 500 列。HDD 適合寫入密集型工作負載，因為讀取作業預期會是與批次處理相關聯的範圍掃描。HDD 儲存空間的價格與 Cloud Storage 相關費用相當或接近，且因區域而異。
叢集大小注意事項
準備遷移 Cassandra 工作負載時，請比較單一資料中心 Cassandra 叢集與單一叢集 Bigtable 執行個體，以及 Cassandra 多個資料中心叢集與多叢集 Bigtable 執行個體，並據此調整 Bigtable 執行個體的大小。下列各節的指南假設遷移時不需要大幅變更資料模型，且 Cassandra 和 Bigtable 之間的儲存空間壓縮率相當。
單一資料中心叢集
比較單一資料中心叢集和單一叢集 Bigtable 執行個體時，請先考量儲存空間需求。您可以使用 nodetool tablestats 命令估算每個鍵空間的未複製大小，並將總計排清的儲存空間大小除以鍵空間的複製因數。接著，將所有鍵空間的未複製儲存空間量除以 3.5 TB (5 TB * 0.70)，即可判斷建議的 SSD 節點數量，以單獨處理儲存空間。如前所述，Bigtable 會在獨立層中處理儲存體複製和耐用性，使用者不會察覺。
接下來，請考量節點數量的運算需求。您可以參考 Cassandra 伺服器和用戶端應用程式指標，取得已執行的持續讀取和寫入作業的大約次數。如要估算執行工作負載所需的最少 SSD 節點數量，請將該指標除以 10,000。如果應用程式需要低延遲查詢結果，可能需要更多節點。Google 建議您使用代表性資料和查詢測試 Bigtable 的效能，為工作負載可達成的每節點 QPS 建立指標。
叢集所需的節點數量應等於儲存空間和運算需求中較大者。如果不確定儲存空間或處理量需求，可以將 Bigtable 節點數量與一般 Cassandra 機器數量進行比對。您可以輕鬆擴充或縮減 Bigtable 叢集，配合工作負載需求，完全不需要停機。
多資料中心叢集
如果叢集位於多個資料中心，就更難判斷 Bigtable 執行個體的設定。理想情況下，您應該在執行個體中為 Cassandra 拓撲中的每個資料中心建立叢集。執行個體中的每個 Bigtable 叢集都必須儲存執行個體內的所有資料，且必須能處理整個叢集的總插入率。您可以在全球任何支援的雲端區域中，建立執行個體中的叢集。
估算儲存空間需求的方法與單一資料中心叢集類似。您可以使用 nodetool 擷取 Cassandra 叢集中每個鍵空間的儲存空間大小，然後將該大小除以副本數量。請注意，資料表的鍵空間在每個資料中心可能會有不同的複製係數。
執行個體中每個叢集的節點數，應能處理叢集中的所有寫入作業，以及至少兩個資料中心的讀取作業，以便在叢集發生中斷時維持服務水準目標 (SLO)。常見的做法是先為所有叢集提供與 Cassandra 叢集中最忙碌的資料中心等量的節點容量。您可以個別擴充或縮減執行個體中的 Bigtable 叢集，以配合工作負載需求，完全不需要停機。
管理
Bigtable 提供全代管元件，可執行 Cassandra 中的常見管理功能。
備份與還原
Bigtable 提供兩種方法，可滿足常見的備份需求： Bigtable 備份和代管資料匯出。
您可以將 Bigtable 備份視為 Cassandra nodetool 快照功能的受管理版本。Bigtable 備份會建立可還原的資料表副本，並以叢集的成員物件形式儲存。您可以將備份還原為新資料表，並存放在啟動備份的叢集。如果發生應用程式層級的損毀，備份功能會建立還原點。透過這項公用程式建立的備份不會耗用節點資源，且價格與 Cloud Storage 價格相近。您可以透過程式輔助或 Bigtable 的 Google Cloud 控制台，叫用 Bigtable 備份。
另一種備份 Bigtable 的方法，是使用代管資料匯出功能，將資料匯出至 Cloud Storage。您可以匯出為 Avro、Parquet 或 Hadoop Sequence 檔案格式。相較於 Bigtable 備份，匯出作業需要較長的時間執行，且會產生額外運算費用，因為匯出作業會使用 Dataflow。不過，這些匯出作業會建立可攜式資料檔案，供您離線查詢或匯入其他系統。
正在調整大小
Bigtable 將儲存空間和運算資源分開，因此您可以根據查詢需求，更順暢地新增或移除 Bigtable 節點，比在 Cassandra 中更輕鬆。Cassandra 的同質架構需要您重新平衡叢集中各機器之間的節點 (或 vnode)。
您可以在 Google Cloud 控制台中手動變更叢集大小，也可以使用 Cloud Bigtable API 以程式輔助方式變更。在叢集中新增節點，幾分鐘內就能明顯提升效能。部分客戶已成功使用 Spotify 開發的開放原始碼自動配置器。
內部維護
Bigtable 服務可無縫處理常見的 Cassandra 內部維護工作，例如 OS 修補、節點復原、節點修復、儲存空間壓縮監控和 SSL 憑證輪替。
監控
將 Bigtable 連線至指標視覺化或快訊功能，不需要管理或開發工作。BigtableGoogle Cloud 控制台頁面提供預先建構的資訊主頁，可追蹤執行個體、叢集和資料表層級的處理量和使用率指標。您可以在 Cloud Monitoring 資訊主頁中建立自訂檢視畫面和快訊，系統會自動提供指標。
Bigtable Key Visualizer 是 Google Cloud 控制台的監控功能，可讓您執行進階效能調整作業。
IAM 和安全性
在 Bigtable 中，授權功能已完全整合至Google Cloud的 IAM 架構，只需進行最基本的設定和維護。系統不會與用戶端應用程式共用本機使用者帳戶和密碼，而是將精細的權限和角色授予機構層級使用者和服務帳戶。
Bigtable 會自動加密所有靜態和傳輸中的資料。您無法停用這些功能。所有管理員權限都會完整記錄。您可以使用 VPC Service Controls，控管核准網路外部對 Bigtable 執行個體的存取權。
後續步驟
- 瞭解 Bigtable 結構定義設計。
- 進一步瞭解 Apache Cassandra。
- 試試適用於 Cassandra 使用者的 Bigtable 程式碼實驗室。
- 瞭解 Bigtable 模擬器。
- 查看 Google Cloud 的參考架構、圖表和最佳做法。歡迎瀏覽我們的 Cloud Architecture Center。