本文適用於軟體開發人員和資料庫管理員，他們想遷移現有應用程式，或設計新應用程式，以便將 Bigtable 做為資料儲存庫。本文會運用您對 Apache Cassandra 的瞭解，說明使用 Bigtable 時應先瞭解的概念，如要瞭解如何使用開放原始碼工具完成遷移作業，請參閱「從 Cassandra 遷移至 Bigtable」。
Bigtable 和 Cassandra 都是分散式資料庫。這些服務實作了多維度鍵值儲存庫，可支援每秒數萬次查詢 (QPS)、儲存高達 PB 級的資料，並容許節點故障。
何時適合將 Cassandra 工作負載遷移至 Bigtable
最適合 Cassandra 工作負載的服務取決於您的遷移目標，以及遷移後所需的 Cassandra 功能。 Google Cloud
如果符合下列一或多項條件，Bigtable 就是最佳選擇：
- 您需要全代管服務，且不希望有維護時段，並要求高可用性。
- 您需要彈性調度資源功能，自動因應伺服器流量變化。
- 您除了純量型別外，還會使用 Cassandra 集合型別、計數器或具體化檢視區塊。
- 您有一個使用
USING TIMESTAMP參數的應用程式。 - 寫入輸送量和延遲時間與讀取同樣重要。
- 您採用 Cassandra 的最終一致性複寫模式。
- 您的用途需要符合成本效益的儲存空間。
如要遷移應用程式，但不想變更任何程式碼，您可以選擇在 GKE 上自行管理 Cassandra，或使用 Google Cloud合作夥伴 (例如 DataStax 或 ScyllaDB)。如果應用程式的讀取作業繁重，且您願意重構程式碼來取得關聯式資料庫功能和同步一致性，不妨考慮使用 Spanner。
如果您選擇 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 的對應。 |
| 對應鍵：在 Cassandra 對應中，可唯一識別鍵/值項目的鍵 | 資料欄限定符：儲存在資料表中的值標籤，由不重複的資料列鍵建立索引。使用 SQL 查詢 Bigtable 時，系統會將資料欄視為對應的鍵。 |
| 資料欄：儲存在資料表中的值的標籤，由專屬主鍵建立索引。 | 資料欄：儲存在資料表中的值標籤，由不重複的資料列鍵建立索引。資料欄名稱是由資料欄系列和資料欄限定詞組合而成。 |
| 儲存格：資料表中的時間戳記值，與主鍵和資料欄的交集相關聯。 | 儲存格：表格中的時間戳記值，與資料列鍵和資料欄名稱的交集相關聯。每個儲存格可儲存及擷取多個加上時間戳記的版本。 |
| counter：可遞增的欄位類型，專為整數加總運算最佳化。 | 計數器：使用專用資料類型進行整數加總運算的儲存格。詳情請參閱「建立及更新計數器」。 |
| 負載平衡政策：您在應用程式邏輯中設定的政策，可將作業轉送至叢集中的適當節點。這項政策會考量資料中心拓撲和 vnode 權杖範圍。 | 應用程式設定檔：相關設定會指示 Bigtable 如何將用戶端 API 呼叫路徑導向執行個體中的適當叢集。您也可以使用應用程式設定檔做為標記，區隔指標。您可以在服務中設定應用程式設定檔。 |
| CQL：Cassandra 查詢語言，類似於 SQL，用於建立資料表、變更結構定義、變動資料列及查詢。 | Bigtable API：用於建立執行個體和叢集、資料表和欄系列、資料列變動和查詢的用戶端程式庫和 gRPC API。Bigtable SQL API 適用於 CQL 使用者。 |
產品總覽
以下各節將概述 Bigtable 和 Cassandra 的設計理念和主要屬性。
Bigtable
Bigtable 提供這篇論文中描述的許多核心功能。Bigtable 會將處理用戶端要求的運算節點，與基礎儲存空間管理作業分開。資料儲存在 Colossus 中。 儲存層會自動複製資料，提供的持久性超越標準 Hadoop 分散式檔案系統 (HDFS) 三路複製所能提供的程度。
這個架構可在叢集內提供一致的讀取和寫入作業，並在擴充及縮減資源時，不會產生任何儲存空間重新分配費用，而且無需修改叢集或結構定義，即可重新平衡工作負載。如果任何資料處理節點發生故障，Bigtable 服務會以公開透明的方式替換節點。Bigtable 也支援非同步複製。
除了 gRPC 和各種程式設計語言的用戶端程式庫，Bigtable 也與開放原始碼 Apache HBase Java 用戶端程式庫保持相容。Apache HBase 是 Bigtable 論文的替代開放原始碼資料庫引擎實作項目。
下圖顯示 Bigtable 如何從儲存層實際分離處理節點：
在上圖中，中間的處理節點只負責為儲存層中的 C 資料集提供資料要求。如果 Bigtable 判斷資料集需要重新平衡範圍指派作業，由於儲存層與處理層是分開的，因此處理節點的資料範圍很容易變更。
下圖以簡化方式顯示鍵範圍重新平衡和叢集大小調整：
「重新平衡」圖片顯示最左側的處理節點收到大量「A」資料集要求後，Bigtable 叢集的狀態。重新平衡後，中間節點會負責處理 B 資料集，而非最左側的節點。最左側的節點會繼續處理 A 資料集的要求。
Bigtable 可以重新排列資料列鍵範圍，以便在增加可用處理節點數量時，平衡資料集範圍。「Resizing」(調整大小) 圖片顯示新增節點後的 Bigtable 叢集狀態。
Cassandra
Apache Cassandra 是開放原始碼資料庫，部分概念受到 Bigtable 文件影響。這項服務採用分散式節點架構，儲存空間與回應資料作業的伺服器位於同一位置。系統會隨機將一系列虛擬節點 (vnode) 指派給每個伺服器，以服務部分叢集鍵空間。
資料會根據分割區鍵儲存在 vnode 中。通常會使用一致性雜湊函式產生權杖，以判斷資料放置位置。與 Bigtable 相同，您可以使用保留順序的分割器產生權杖，進而放置資料。不過，Cassandra 文件不建議採用這種做法，因為叢集很可能會失去平衡，而這種情況很難補救。因此，本文假設您使用一致性雜湊策略產生權杖，以便在節點間分配資料。
Cassandra 提供容錯能力，可用性層級與可調整的一致性層級相關聯，因此當一或多個節點受損時，叢集仍可為用戶端提供服務。您可以透過可設定的資料複製拓撲策略，定義地理位置複製作業。
您可以為每個作業指定一致性層級。一般設定為 QUORUM (或特定多資料中心拓撲中的 LOCAL_QUORUM)。如要將作業視為成功，這個一致性層級設定需要多數副本節點回應協調器節點。您為每個鍵空間設定的複寫因數，會決定叢集內每個資料中心儲存的資料副本數量。舉例來說，一般會使用 3 的複寫因數值，在耐久性和儲存空間容量之間取得實用平衡。
下圖以簡化方式顯示六個節點的叢集，每個節點的金鑰範圍都劃分為五個虛擬節點。在實務上，您可以擁有更多節點，而且可能會擁有更多虛擬節點。
在上圖中，您可以看到寫入作業的路徑，一致性層級為 QUORUM，源自用戶端應用程式或服務 (「用戶端」)。為方便說明，下圖顯示的鍵範圍為字母範圍。實際上，主要金鑰雜湊產生的符記是很大的帶正負號整數。
在這個範例中，金鑰雜湊是 M，而 M 的 vnode 位於節點 2、4 和 6。協調器必須聯絡每個本機儲存鍵雜湊範圍的節點，才能處理寫入作業。由於一致性層級為 QUORUM，因此必須有兩個備用資源 (大多數) 回應協調器節點，用戶端才會收到寫入完成的通知。
與 Bigtable 不同，在 Cassandra 中移動或變更鍵範圍時，必須將資料從一個節點實際複製到另一個節點。如果某個節點因特定權杖雜湊範圍的要求而過載，與 Bigtable 相比，在 Cassandra 中為該權杖範圍新增處理作業會更加複雜。
地理位置複製和一致性
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 中的節點會自動平衡金鑰範圍的節點責任，這些金鑰範圍通常稱為「平板電腦」，有時也稱為「分割」。Bigtable 資料列索引鍵通常由多個欄位值組成，並使用您選擇的常用分隔字元 (例如百分比符號) 聯結。分開後，個別字串元件會類似於 Cassandra 主鍵的欄位。
資料列索引鍵設計
在 Bigtable 中，資料表資料列的專屬 ID 是資料列鍵。資料列鍵在整個表格中必須是單一不重複的值。您可以串連以常見分隔符號分隔的不同元素，建立多部分金鑰。資料列鍵決定資料表中的全域資料排序順序。Bigtable 服務會動態決定指派給每個節點的金鑰範圍。
與 Cassandra 不同的是，在 Cassandra 中，分割區鍵雜湊會決定資料列的放置位置，叢集資料欄則會決定排序方式；在 Bigtable 中，資料列鍵會同時提供節點指派和排序功能。與 Cassandra 相同，您應在 Bigtable 中設計資料列鍵，以便將要一起擷取的資料列儲存在一起。不過，在 Bigtable 中，您不必先設計用於放置和排序的資料列鍵，再使用資料表。
資料類型
Bigtable 服務不會強制執行用戶端傳送的資料欄資料類型。用戶端程式庫提供輔助方法，可將儲存格值寫入為位元組、UTF-8 編碼字串，以及大端序編碼的 64 位元整數 (原子遞增作業需要大端序編碼的整數)。
資料欄系列
在 Bigtable 中，資料欄系列會決定資料表中哪些資料欄會一起儲存及擷取。每個資料表至少需要一個資料欄系列，但資料表通常會有更多資料欄系列 (每個資料表最多 100 個資料欄系列)。您必須明確建立資料欄系列，應用程式才能在作業中使用這些系列。
資料欄限定詞
儲存在資料表列鍵的值都會與稱為「資料欄限定符」的標籤建立關聯。由於欄位限定詞只是標籤，因此欄位系列中可擁有的欄位數量實際上沒有限制。資料欄限定詞通常用於 Bigtable，代表應用程式資料。
儲存格
在 Bigtable 中，儲存格是資料列鍵和資料欄名稱 (資料欄系列加上資料欄限定詞) 的交集。每個儲存格都包含一或多個帶有時間戳記的值，這些值可由用戶端提供，或由服務自動套用。系統會根據在資料欄系列層級設定的垃圾收集政策，回收舊的儲存格值。
次要索引
Bigtable 不支援次要索引。如果需要索引，建議您使用資料表設計，也就是使用具有不同資料列鍵的第二個資料表。
用戶端負載平衡和容錯移轉
在 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 中，由於每個資料列鍵在任何時間點只會指派給單一節點，因此只要收到節點的回應，就能確認寫入作業是否成功。
之後如有需要，您可以將記憶體內資料表以新 SSTable 的形式排清至磁碟。在 Cassandra 中，當提交記錄達到大小上限，或記憶體內資料表超過您設定的門檻時，就會發生排清作業。在 Bigtable 中，當記憶體內資料表達到服務指定的上限時，系統會啟動排清作業，建立新的immutable SSTable。壓縮程序會定期將特定鍵範圍的 SSTable 合併為單一 SSTable。
資料更新
這兩個資料庫處理資料更新的方式類似。不過，Cassandra 每個儲存格只能有一個值，而 Bigtable 每個儲存格可保留大量版本值。
當專屬資料列 ID 和資料欄的交集值遭到修改時，系統會按照「資料寫入程序」一節所述，保留更新內容。寫入時間戳記會與 SSTable 結構中的值一併儲存。
如果尚未將更新的儲存格排清至 SSTable，您只能將儲存格值儲存在記憶體內資料表，但資料庫儲存的內容有所不同。Cassandra 只會在記憶體資料表儲存最新值，而 Bigtable 則會在記憶體資料表儲存所有版本。
或者，如果您已將至少一個版本的儲存格值排清至磁碟中的個別 SSTable，資料庫會以不同的方式處理該資料的要求。向 Cassandra 要求儲存格時，系統只會根據時間戳記傳回最新值；換句話說，最後寫入的值會勝出。在 Bigtable 中，您可以使用篩選器，控制讀取要求傳回的儲存格版本。
刪除列
由於這兩個資料庫都使用不可變動的 SSTable 檔案將資料保存到磁碟，因此無法立即刪除資料列。為確保查詢在刪除資料列後傳回正確結果，這兩個資料庫會使用相同機制處理刪除作業。系統會先將標記 (在 Cassandra 中稱為「墓碑」) 新增至記憶體資料表。最終，新寫入的 SSTable 會包含時間戳記標記，指出已刪除專屬資料列 ID，且不應在查詢結果中傳回。
存留時間 (TTL)
這兩個資料庫的存留時間 (TTL) 功能類似，但有一項差異。在 Cassandra 中，您可以為資料欄或資料表設定存留時間，但在 Bigtable 中，您只能為資料欄系列設定存留時間。Bigtable 提供可模擬儲存格層級存留時間的方法。
垃圾收集
如先前所述，由於 SSTable 不可變動，因此無法立即更新或刪除資料，垃圾收集作業會在壓縮程序中進行。這個程序會移除不應顯示在查詢結果中的儲存格或列。
發生 SSTable 合併時，垃圾收集程序會排除資料列或儲存格。如果資料列有標記或墓碑，該資料列就不會納入產生的 SSTable。這兩個資料庫都可以從合併的 SSTable 中排除儲存格。如果儲存格時間戳記超過 TTL 資格，資料庫會排除該儲存格。如果特定儲存格有兩個加上時間戳記的版本，Cassandra 只會在合併的 SSTable 中納入最新值。
資料讀取路徑
讀取作業抵達適當的處理節點時，這兩個資料庫取得資料以滿足查詢結果的讀取程序相同。
對於磁碟上可能包含查詢結果的每個 SSTable，系統會檢查 Bloom 篩選器，判斷每個檔案是否包含要傳回的資料列。由於 Bloom 篩選器保證絕不會提供誤判為否定的結果，因此所有符合資格的 SSTable 都會加入候選清單，以便納入後續的讀取結果處理程序。
讀取作業是透過從記憶體資料表和磁碟上的候選 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 提供更強大的一致性保證。
透過 Colossus 提供的複製功能，Bigtable 可確保資料持久性。
下圖說明 Bigtable 的實體資料配置、運算處理節點和路由層：
在 Colossus 儲存層中，每個節點都會指派為一系列 SSTable 中儲存的資料提供服務。這些 SSTable 包含動態指派給每個節點的資料列鍵範圍資料。雖然圖表顯示每個節點有三個 SSTable，但實際上可能更多，因為節點收到新的資料變更時，會持續建立 SSTable。
每個節點都有共用記錄。 每個節點處理的寫入作業會立即保存至共用記錄，然後用戶端才會收到寫入確認。由於寫入 Colossus 的資料會多次複製，因此即使節點硬體在資料保存至資料列範圍的 SSTable 之前發生故障，系統仍可保證資料耐久性。
應用程式介面
原本 Cassandra 資料庫存取權是透過 Thrift API 公開，但這種存取方法已淘汰。建議透過 CQL 與用戶端互動。
與 Cassandra 的原始 Thrift API 類似，Bigtable 資料庫存取權是透過 API 提供，可根據提供的資料列鍵讀取及寫入資料。
與 Cassandra 類似，Bigtable 也有指令列介面 (稱為 cbt CLI)，以及支援多種常見程式設計語言的用戶端程式庫。這些程式庫是以 gRPC 和 REST API 為基礎建構而成。為 Hadoop 撰寫的應用程式，如果使用適用於 Java 的開放原始碼 Apache HBase 程式庫，不需要大幅變更即可連線至 Bigtable。如果應用程式不需要 HBase 相容性，建議您使用內建的 Bigtable Java 用戶端。
Bigtable 的身分與存取權管理 (IAM) 控制項與 Google Cloud完全整合，資料表也可以做為 BigQuery 的外部資料來源。
資料庫設定
設定 Cassandra 叢集時，您需要做出多項設定決策，並完成多個步驟。首先，您必須設定伺服器節點，提供運算容量並佈建本機儲存空間。使用建議且最常見的複寫係數 3 時，您必須佈建儲存空間，才能儲存預期叢集資料量的三倍。您也必須決定並設定 vnode、機架和複寫的設定。
與 Cassandra 相比，Bigtable 將運算資源與儲存空間分開，因此叢集資源調度作業更加簡單。在正常運作的叢集中，您通常只會關心受管理資料表使用的總儲存空間，這會決定節點的最低數量，以及是否有足夠的節點來維持目前的每秒查詢數 (QPS)。
如果叢集根據生產負載過度或不足佈建，您可以快速調整 Bigtable 叢集大小。
Bigtable 儲存空間
除了初始叢集的地理位置，建立 Bigtable 執行個體時，您只需要選擇儲存空間類型。Bigtable 提供兩種儲存空間選項：固態硬碟 (SSD) 或硬碟 (HDD)。執行個體中的所有叢集必須共用相同的儲存空間類型。
使用 Bigtable 估算儲存空間需求時，不需要像調整 Cassandra 叢集大小一樣，估算儲存空間副本。與 Cassandra 不同，您不必犧牲儲存密度，就能達到容錯能力。此外，由於不需要明確佈建儲存空間，因此您只需支付實際使用的儲存空間費用。
SSD
SSD 節點的容量為 5 TB，適合大多數工作負載，與 Cassandra 機器的建議設定相比，儲存密度更高。Cassandra 機器的每個節點實際最大儲存密度不到 2 TB。評估儲存空間容量需求時，請注意 Bigtable 只會計算一份資料副本；相較之下，在大多數設定下，Cassandra 需要計算三份資料副本。
SSD 的寫入 QPS 與 HDD 大致相同，但讀取 QPS 遠高於 HDD。SSD 儲存空間的價格與佈建的 SSD 永久磁碟成本相近，且會因地區而異。
HDD
HDD 儲存空間類型可提供相當高的儲存空間密度，每個節點可達 16 TB。但缺點是隨機讀取速度會大幅降低，每個節點每秒只能讀取 500 個資料列。如果工作負載需要大量寫入，且預期讀取作業會是與批次處理相關的範圍掃描，則建議使用 HDD。HDD 儲存空間的價格與 Cloud Storage 相關費用相近，且會因區域而異。
叢集大小注意事項
準備遷移 Cassandra 工作負載時，請考量如何調整 Bigtable 執行個體的大小，並比較單一資料中心 Cassandra 叢集與單一叢集 Bigtable 執行個體，以及 Cassandra 多資料中心叢集與多叢集 Bigtable 執行個體。下列各節的指南假設遷移時不需要大幅變更資料模型，且 Cassandra 和 Bigtable 之間有同等的儲存空間壓縮率。
單一資料中心叢集
比較單一資料中心叢集與單一叢集 Bigtable 執行個體時，請先考量儲存空間需求。您可以使用 nodetool tablestats 指令估算每個鍵空間的未複製大小，並將總計排清的儲存空間大小除以鍵空間的複製因數。接著，將所有鍵空間的未複製儲存空間量除以 3.5 TB (5 TB * .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 序列檔案格式。相較於 Bigtable 備份，匯出作業需要較長的時間，且會產生額外的運算費用，因為匯出作業會使用 Dataflow。不過，這些匯出作業會建立可攜式資料檔案，方便您離線查詢或匯入其他系統。
正在調整大小
由於 Bigtable 將儲存空間和運算資源分開，因此相較於 Cassandra，您可以更順暢地因應查詢需求新增或移除 Bigtable 節點。Cassandra 的同質架構要求您在叢集中的機器之間重新平衡節點 (或虛擬節點)。
您可以在 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 結構定義設計。
- 歡迎試試適用於 Cassandra 使用者的 Bigtable 程式碼研究室。
- 瞭解 Bigtable 模擬器。
- 探索 Google Cloud 的參考架構、圖表和最佳做法。 歡迎瀏覽我們的雲端架構中心。