本文档适用于想要迁移现有应用或设计新应用（以数据存储区形式）使用 Bigtable 的软件开发者和数据库管理员。本文档假设您具备使用 Bigtable 所需的 Apache Cassandra 知识。
Bigtable 和 Cassandra 是分布式数据库。它们实施多维键值对存储区，可以支持每秒数以万计的查询次数 (QPS)、扩缩能力高达 PB 数据级的存储空间，以及容忍节点故障。
虽然这些数据库的特征集在整体上相似，但是它们的基础架构和交互细节在对于理解很重要的方面有所不同。本文档重点介绍了两种数据库系统之间的异同。
何时将 Bigtable 用作 Cassandra 工作负载的目标位置
最适合您的 Cassandra 工作负载的 Google Cloud 服务取决于您的迁移目标以及迁移后您需要的 Cassandra 功能。
如果写入的吞吐量和延迟时间与读取一样重要，Bigtable 是最佳选择。得益于 Bigtable 的最终一致性、快速本地写入、使用自定义时间戳的功能、灵活的架构（例如可更新的集合类型）和各种集群拓扑，Bigtable 能够支持不断演变的应用，并以经济高效的方式实现低延迟。
如需在不更改任何代码的情况下迁移应用，您可以选择在 GKE 上自行管理 Cassandra，也可以使用 DataStax 或 ScyllaDB 等 Google Cloud 合作伙伴。如果您的应用是读取密集型应用，并且您愿意重构代码以获得关系型数据库功能和强一致性，不妨考虑使用 Spanner。
如果您选择 Bigtable 作为 Cassandra 工作负载的迁移目标，本文档提供了有关在重构应用时需要考虑的事项的提示。
如何使用此文档
您无需通读此文档。虽然此文档比较了两个数据库，但您也可以关注适用于您的使用场景或兴趣的主题。
比较两个成熟的数据库并非简单的任务。为此，此文档将执行以下操作：
- 比较术语，这在两个数据库之间可能有所不同。
- 概述了两个数据库系统。
- 介绍每个数据库如何处理数据建模，以了解不同的设计注意事项。
- 比较写入和读取期间数据所采用的路径。
- 检查物理数据布局，了解数据库架构的各个方面。
- 介绍如何配置地理位置复制以满足需求，以及如何处理集群大小调整。
- 查看有关集群管理、监控和安全性的详细信息。
术语比较
虽然 Bigtable 和 Cassandra 中使用的许多概念类似，但每个数据库的命名约定和细微差别略有不同。
两个数据库的核心构建块之一都是排序字符串表 (SSTable)。在两种架构中，系统都会创建 SSTable 来保留用于响应读取查询的数据。
在博文 (2012)，Ilya Grigorik 撰写以下内容：“SSSTable 是一个简单的抽象层，可以高效存储大量键值对，并针对高吞吐量、顺序读写工作负载进行优化。”
下表概括说明了共享概念，并说明了每种产品使用的相应术语：
| Cassandra | Bigtable |
|---|---|
|
主键：确定具有数据布置和排序的唯一单字段或多字段值。 分区键：按统一哈希确定数据布置的单字段或多字段值。 聚类列：确定指定分区中按字典数据排序的单字段或多字段值。 |
行键：唯一的单字节字符串，按字典排序确定数据的布置。如需模仿复合键，您可以使用公共分隔符（例如哈希符号 (#) 或百分比 (%)）联接多列数据。 |
| 节点：一台负责读取和写入与一系列主键分区哈希范围关联的数据的计算机。在 Cassandra 中，数据存储在挂接到节点服务器的块级存储上。 | 节点：一种负责读取和写入与一系列行键范围关联的数据的虚拟计算资源。在 Bigtable 中，数据与计算节点不位于同一位置。而是存储在 Google 分布式文件系统 Colossus 中。节点会根据操作负载和集群中其他节点的运行状况临时负责提供各种数据范围。 |
|
数据中心：与 Bigtable 集群类似，但拓扑和复制策略的某些方面可在 Cassandra 中配置。 机架：影响副本放置的数据中心内的节点分组。 |
集群：一组位于同一地理位置的 Google Cloud 可用区中的节点，旨在应对延迟和复制问题。 |
| 集群：Cassandra 部署由一个数据中心集合组成。 | 实例：发生复制和连接路由的不同 Google Cloud 可用区或区域中的一组 Bigtable 集群。 |
| 虚拟节点：分配给特定物理节点的固定哈希值范围。虚拟节点中的数据实际存储在 Cassandra 节点上的一系列 SSTable 中。 | 片：此 SSTable 包含按字典顺序排序的行键连续范围的所有数据。片未存储在 Bigtable 的节点上，但存储在 Colossus 上的一系列 SSTable 中。 |
| 复制因子：某个虚拟节点在数据中心的所有节点中维护的副本数。系统会为每个数据中心独立配置复制因子。 | 复制：将 Bigtable 中存储的数据复制到实例中所有集群的过程。可用区集群中的复制由 Colossus 存储层处理。 |
| 表（以前称为列族）：按唯一主键编入索引的值的逻辑组织。 | 表：按唯一行键编入索引的值的逻辑组织。 |
| 键空间：此逻辑表命名空间用于定义其所含表的复制因子。 | 不适用。Bigtable 以透明的方式处理键空间问题。 |
| map：用于存储键值对的 Cassandra 集合类型。 | 列族：用户指定的命名空间，用于对列限定符进行分组以提升读写效率。使用 SQL 查询 Bigtable 时，列族会被视为 Cassandra 中的映射。 |
| 映射键：用于唯一标识 Cassandra 映射中的键值对条目的键 | 列限定符：在由唯一行键编入索引的表中存储的值的标签。使用 SQL 查询 Bigtable 时，列会被视为映射的键。 |
| 列：在由唯一主键编入索引的表中存储的值的标签。 | 列：在由唯一行键编入索引的表中存储的值的标签。通过将列族与列限定符进行组合来构造列名称。 |
| 单元格：与列的主键的交集相关联的表中的时间戳值。 | 单元格：与列名称的行键的交集相关联的表中的时间戳值。您可以为每个单元格存储和检索多个带有时间戳的版本。 |
| counter：一种可递增字段类型，专为整数求和运算进行了优化。 | 计数器：使用专用数据类型进行整数求和运算的单元格。如需了解详情，请参阅创建和更新计数器。 |
| 负载平衡政策：您在应用逻辑中配置的政策，用于将操作路由到集群中的相应节点。此政策会考虑数据中心拓扑和虚拟节点令牌范围。 | 应用配置文件：指示 Bigtable 如何将客户端 API 调用路由到实例中的相应集群的设置。您还可以将应用配置文件用作指标细分标记。您可以在服务中配置应用配置文件。 |
| CQL：Cassandra 查询语言，诸如 SQL 之类的语言，用于创建表、更改架构、更改行以及查询。 | Bigtable API：客户端库和 gRPC API，用于创建实例和集群、创建表和列族、变更行以及进行查询。CQL 用户会熟悉 Bigtable SQL API。 |
产品概览
以下部分简要介绍了 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 可以重新排列行键范围，以便使更多可用处理节点中的数据集范围保持平衡。添加节点后，重新调整大小图片显示了 Bigtable 集群的状态。
Cassandra
Apache Cassandra 是一个开源数据库，受 Bigtable 白皮书中的概念的影响。它使用分布式节点架构，其中存储与响应数据操作的服务器位于同一位置。系统会为每个服务器随机分配一系列虚拟节点来处理一部分集群键空间。
数据基于分区键存储在虚拟节点中。通常，系统会使用一致的哈希函数来生成令牌以确定数据的位置。与 Bigtable 一样，您可以使用订单保留分区来生成令牌，因此也可用于数据放置。但是，Cassandra 文档不建议使用这种方法，因为集群很可能变得不平衡，造成情况难以补救。因此，本文档假设您使用一致的哈希策略来生成会跨节点分布数据的令牌。
Cassandra 通过与可调整一致性级别相关的可用性级别来提供容错能力，使集群能够在一个或多个节点受损时为客户端提供服务。您可以通过可配置的数据复制拓扑策略定义地理位置复制功能。
您需要为每项操作指定一致性级别。典型设置为 QUORUM（在某些多数据中心拓扑中，或为 LOCAL_QUORUM）。此一致性级别设置要求大多数副本节点响应协调者节点，才能将操作视为成功。您为每个键空间配置的复制因子确定存储在集群中每个数据中心的数据副本数量。例如，通常使用复制因子值 3 在耐用性和存储卷之间提供实际平衡。
下图展示了简化的集群，其中有六个节点，每个节点的键范围分为 5 个虚拟节点。实际上，您可以拥有更多节点，并且可能拥有更多虚拟节点。
在上图中，您可以看到写入操作的路径，其一致性级别为 QUORUM，其源自客户端应用或服务（客户端）。在本图中，键范围显示为字母范围。实际上，由主键的哈希生成的令牌是非常大的带符号整数。
在此示例中，密钥哈希为 M，M 的虚拟节点位于节点 2、4、6 中。协调者必须与键哈希范围存储于本地的每个节点联系，以便可以处理写入。由于一致性级别是 QUORUM，因此两个副本（大多数）都必须响应协调者节点，然后才会通知客户端写入已完成。
与 Bigtable 相比，在 Cassandra 中移动或更改密钥范围会要求您以物理方式将数据从一个节点复制到另一个节点。如果一个节点由于针对给定令牌哈希范围的请求而过载，则在 Cassandra 中针对该令牌范围添加处理要比在 Bigtable 中更复杂。
地理位置复制和一致性
Bigtable 和 Cassandra 以不同方式处理地理位置（也称为多区域）复制和一致性。Cassandra 集群包含归入机架的处理节点，而机架会归入数据中心。Cassandra 使用您配置的网络拓扑策略来确定如何在数据中心的主机之间分布虚拟节点副本。此策略将 Cassandra 的根数据库显示为最初部署在物理本地数据中心上的数据库。此配置还为集群中的每个数据中心指定复制因子。
Cassandra 使用数据中心和机架配置来提高数据副本的容错能力。在读取和写入操作期间，拓扑确定提供一致性保证所需的参与者节点。创建或扩展集群时，必须手动配置节点、机架和数据中心。在云环境中，典型的 Cassandra 部署将云可用区视为机架，将云区域视为数据中心。
您可以使用 Cassandra 的仲裁控件来调整每个读取或写入操作的一致性保证。最终一致性强度级别可能各不相同，包括需要单个副本节点 (ONE)、单数据中心副本节点的大多数 (LOCAL_QUORUM) 或所有数据中心中所有副本节点的大多数 (QUORUM) 的选项。
在 Bigtable 中，集群是地区资源。一个 Bigtable 实例可以包含单个集群，也可以是一个完全复制的集群组。您可以将实例集群放到 Google Cloud 提供的任何区域中的任意可用区组合中。您可以在某个实例中添加和移除集群，这对实例中的其他集群几乎没有影响。
在 Bigtable 中，写入（采用读己所写 (read-your-writes) 一致性）在单个集群上执行，并且将在其他实例集群中最终保持一致。由于各个单元格都是按时间戳进行版本控制，因此不会丢失任何写入，并且每个集群都会提供具有可用最新时间戳的单元格。
服务会公开集群一致性状态。Cloud Bigtable API 提供一种获取表级别一致性令牌的机制。您可以使用此令牌确定是否已完全复制在创建令牌之前对该表所做的所有更改。
事务支持
虽然两个数据库都不支持复杂的多行事务，但每个数据库都有部分事务支持。
Cassandra 具有一个轻量级事务 (LWT) 方法，提供的原子性可用于更新单个分区中的列值。Cassandra 还具有比较和设置语义，用于在启动写入之前完成行读取操作和值比较。
Bigtable 支持在集群内实现完全一致的单行写入。通过读取-修改-写入和检查并更改操作可进一步启用单行事务。多集群路由应用配置文件不支持单行事务。
数据模型
Bigtable 和 Cassandra 都将数据整理成表，以支持使用行的唯一标识符进行查询和范围扫描。这两个系统均归类为 NoSQL 宽列存储。
在 Cassandra 中，您必须使用 CQL 提前创建完整表架构，包括主键定义以及列名称及其类型。Cassandra 中的主键是唯一的复合值，由必需的分区键和可选的集群键组成。分区键确定行的节点放置，而集群键确定分区中的排序顺序。创建架构时，您必须了解，在单个分区内执行高效扫描和与维护大型分区关联的系统费用之间的潜在取舍。
在 Bigtable 中，您只需提前创建表并定义其列族。创建表时，系统不会声明列，但会在应用 API 调用向表行添加单元格时创建这些列。
行键以字典顺序跨 Bigtable 集群排序。Bigtable 中的节点会自动平衡键范围的节点责任，通常称为片，有时称为分块。Bigtable 行键通常包含使用您所选的常用分隔符（例如百分号）联接的多个字段值。分离时，各个字符串组成部分类似于 Cassandra 主键的字段。
行键设计
在 Bigtable 中，表行的唯一标识符是行键。行键必须为整个表中的单个唯一值。您可以通过串联各个元素（由通用分隔符分隔）来创建多部分键。行键确定表中的全局数据排序顺序。Bigtable 服务会动态确定分配给每个节点的键范围。
在 Cassandra 中，分区键哈希确定行放置，而集群列确定排序，相比而言 Bigtable 行键同时提供节点分配和排序。与 Cassandra 一样，您应该以 Bigtable 设计行键，使您希望一起检索的行存储在一起。但在 Bigtable 中，您使用表前，无需使用行键设计行键和排序功能。
数据类型
Bigtable 服务不会强制执行客户端发送的列数据类型。客户端库提供辅助方法以字节、UTF-8 编码字符串和大端字节序 64 位编码整数（原子增量操作需要使用大端字节序编码整数）写入单元格值。
列族
在 Bigtable 中，列族确定一起存储和检索的表列。每个表至少需要一个列族，但表通常具有更多个（每个表的列族数上限为 100 个）。您必须先显式创建列族，然后应用才能在操作中使用列族。
列限定符
存储在行键的表中的每个值都与名为列限定符的标签相关联。由于列限定符只是标签，因此列族中可以具有的列数没有实际限制。Bigtable 中通常使用列限定符来表示应用数据。
单元格
在 Bigtable 中，单元格是行键和列名称（列族与列限定符组合）的交集。每个单元格都包含一个或多个由时间戳提供的值，该值可以由客户端提供或由服务自动应用。系统会根据列族级层配置的垃圾回收政策来回收旧单元格值。
二级索引
Bigtable 不支持二级索引。如果需要索引，我们建议您使用采用具有不同行键的另一个表的表设计。
客户端负载均衡和故障切换
在 Cassandra 中，客户端控制请求的负载平衡。客户端驱动程序会设置政策，该政策可指定为配置的一部分，也可以在会话创建期间以编程方式指定。集群会向政策告知离应用最近的数据中心，而客户端会标识来自这些数据中心的节点来处理操作。
Bigtable 服务会根据每个操作提供的参数（应用配置文件标识符）将 API 调用路由到目标集群。应用配置文件在 Bigtable 服务中进行维护；未选择配置文件的客户端操作会使用默认配置文件。
Bigtable 有两种类型的应用配置文件路由政策：单集群和多集群。多集群配置文件将操作路由到距离最近的可用集群。从操作路由器的角度，同一区域中的集群被视为等距离。如果负责所请求键范围的节点过载或在集群中暂时不可用，此配置文件类型可以提供自动故障切换。
就 Cassandra 来说，多集群政策提供可感知数据中心的负载均衡政策的故障切换优势。
具有单集群路由的应用配置文件会将所有流量定向到单个集群。只有采用单集群路由的配置文件提供强行一致性和单行事务功能。
单集群方法的缺点是，在故障切换中，应用必须能够使用替代应用配置文件标识符重试，或者您必须对受影响的单集群路由配置文件手动执行故障切换。
操作路由
Cassandra 和 Bigtable 使用不同的方法为读取和写入操作选择处理节点。Cassandra 中标识分区键，而 Bigtable 中则使用行键。
在 Cassandra 中，客户端首先检查负载平衡政策。此客户端对象确定会将操作路由到的数据中心。
标识数据中心后，Cassandra 会联系协调者节点来管理操作。如果政策识别令牌，则协调者是一个从目标虚拟节点分区提供数据的节点；否则，协调者是一个随机节点。协调者节点标识操作分区键的数据副本所在的节点，然后指示这些节点执行操作。
如前所述，在 Bigtable 中，每项操作都包含应用配置文件标识符。应用配置文件在服务级别定义。Bigtable 路由层会检查配置文件，以便为操作选择适当的目标集群。然后，路由层使用操作的行键，为操作提供到达正确处理节点的路径。
数据写入过程
两个数据库都针对快速写入进行了优化，并且使用类似的过程来完成写入。但是，数据库执行的步骤略有不同，尤其是 Cassandra 可能需要与其他参与者节点进行通信，具体取决于操作一致性级别。
将写入请求路由到相应的多个节点 (Cassandra) 或一个节点 (Bigtable) 后，写入操作首先通过提交日志 (Cassandra) 或共享日志 (Bigtable) 依次保存到磁盘。接下来，将写入插入到排序如同 SSTable 的内存中表（也称为 memtable）。
完成这两个步骤后，节点会做出响应，指示写入已完成。在 Cassandra 中，多个副本（具体取决于为每个操作指定的一致性级别）必须在协调者告知客户端写入已完成之前做出响应。在 Bigtable 中，由于每个行键在任何时间点都仅分配给一个节点，因此节点的响应只需确认确认是否成功。
之后，如果需要，您可以以新 SSTable 的形式将 memtable 刷新到磁盘上。在 Cassandra 中，当提交日志达到大小上限或 memtable 超过您配置的阈值时，会进行刷新。在 Bigtable 中，当 memtable 达到服务指定的大小上限时，系统会启动刷新操作，创建新的不可变 SSTable。收紧过程会定期将给定键范围的 SSTable 合并到一个 SSTable 中。
数据更新
两个数据库以类似方式处理数据更新。但是，Cassandra 仅允许每个单元格使用一个值，而 Bigtable 可以为每个单元格保留大量有版本记录的值。
当修改唯一行标识符与列相交处的值时，更新操作将按前文的数据写入过程部分所述方式保留。写入时间戳与值一起存储在 SSTable 结构中。
如果您尚未将更新后的单元格刷新到 SSTable，则可以将单元格值仅存储在 memtable 中，但这两个数据库在存储内容方面有差异。Cassandra 只保存 memtable 中的最新值，而 Bigtable 会在 memtable 中保存所有版本。
或者，如果您已在单独的 SSTable 中将至少一个版本的单元格值刷新到磁盘，这两个数据库会以不同方式处理这些对该数据的请求。从 Cassandra 请求单元格时，仅返回基于时间戳的最新值；换句话说，最后一次的写入内容胜出。在 Bigtable 中，您可使用过滤器控制读取请求返回的单元格版本。
行删除
由于两个数据库使用不可变 SSTable 文件将数据持久保留到磁盘，因此无法立即删除行。为确保在删除行后查询返回正确的结果，两个数据库都使用相同的机制处理删除。系统首先向 memtable 中添加一个标记（在 Cassandra 中称为 Tombstone）。最后，新写入的 SSTable 包含一个带时间戳的标记，用于指示唯一行标识符已被删除，查询结果中不应返回该标记。
生存时间
两个数据库中的存留时间 (TTL) 功能相似，但有一项差异。在 Cassandra 中，您可以为列或表设置 TTL；但在 Bigtable 中，您只能为列族设置 TTL。Bigtable 中有一种可以模拟单元格级别 TTL 的方法。
垃圾回收
由于正如之前所述的那样，无法利用不可变 SSTable 实现立即数据更新或删除数据，因此垃圾回收是在称为压缩的过程中进行的。该过程会移除不应在查询结果中提供的单元格或行。
进行 SSTable 合并时，垃圾回收过程会排除一行或单元格。如果某行存在标记或 Tombstone，不会将该行包含在结果 SSTable 中。两个数据库都可以从合并的 SSTable 中排除一个单元格。如果单元格时间戳超出 TTL 资格，则数据库将排除单元格。如果给定单元格有两个带时间戳的版本，则 Cassandra 将只包含合并的 SSTable 中的最新值。
数据读取路径
当读取操作到达相应的处理节点时，获取满足查询结果所需的读取过程对于两个数据库而言是相同的。
对于可能包含查询结果的磁盘上的每个 SSTable，系统会检查 Bloom 过滤器，以确定每个文件是否包含要返回的行。由于 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，因为节点接收数据新更改时会持续创建 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 的 Identity and Access Management (IAM) 控件与 Google Cloud 完全集成，并且表也可用作 BigQuery 外部数据源。
数据库设置
设置 Cassandra 集群时，您需要制定一些配置决策并完成一些步骤。首先，您必须配置服务器节点以提供计算容量和预配本地存储。如果使用复制因子 3（建议的设置且是最常用的设置），则必须预配存储空间来存储您预期保留在集群中的数据量的三倍。您还必须确定并设置虚拟节点、机架和复制配置。
相比 Cassandra，在 Bigtable 中将计算与存储分开可简化集群扩缩。在正常运行的集群中，通常只关注托管表使用的总存储空间，从而确定最小节点数，以及有足够的节点来维持当前的 QPS。
如果根据生产负载进行集群过度预配或预配不足，您可以快速调整 Bigtable 集群大小。
Bigtable 存储
除 Bigtable 集群的地理位置以外，您在创建 Bigtable 实例时唯一需要选择的是存储类型。Bigtable 提供两个存储选项：固态硬盘 (SSD) 或普通硬盘 (HDD)。一个实例中的所有集群必须具有相同的存储类型。
当您将 Bigtable 的存储需求考虑在内时，无需在考虑 Cassandra 集群大小时考虑存储副本。Cassandra 中未出现牺牲存储密度来实现容错的情况。此外，由于存储不必进行明确预配，因此您只需要为使用的存储空间付费。
SSD
SSD 节点的容量为 5 TB，它对于大多数工作负载而言都是首选配置，与 Cassandra 机器的建议配置相比，它可以提供更高的存储密度，而后者的实际存储密度上限为每个节点低于 2 TB。在评估存储容量需求时，请记住 Bigtable 仅计算数据的一个副本；相比之下，Cassandra 在大多数配置下都需要考虑三个数据副本。
虽然 SSD 的 QPS 大约与 HDD 相同，但 SSD 提供的读取 QPS 明显高于 HDD。SSD 存储的价格等于或接近预配的 SSD 永久性磁盘的费用，或者会因区域而异。
HDD
HDD 存储类型可实现相当大的存储密度，即每个节点 16 TB。权衡性在于随机读取速度明显变慢，仅支持每个节点每秒读取 500 行。对于读取预计为与批处理关联的范围扫描的写入密集型工作负载，首选 HDD。HDD 存储的价格等于或接近与 Cloud Storage 关联的费用，或者会因区域而异。
集群大小注意事项
当您调整 Bigtable 实例的大小以准备迁移 Cassandra 工作负载时，在比较单数据中心 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 将存储和计算分开，因此您可以添加或移除 Bigtable 节点以响应查询需求，这比 Cassandra 中的查询更顺畅。Cassandra 的同构架构要求您在集群中的各计算机之间再次平衡节点（或虚拟节点）。
您可以在 Google Cloud 控制台中手动更改集群大小，也可以使用 Cloud Bigtable API 以编程方式更改集群大小。向集群添加节点可以在几分钟之内显著提升性能。一些客户已成功使用 Spotify 开发的开源自动扩缩器。
内部维护
Bigtable 服务可以无缝应对常见的 Cassandra 内部维护任务，例如操作系统修补、节点恢复、节点修复、存储压缩监控和 SSL 证书轮替。
监控
将 Bigtable 连接到指标可视化或提醒不需要管理或开发工作。Bigtable Google Cloud 控制台页面附带预构建的信息中心，用于跟踪实例、集群和表级别的吞吐量和利用率指标。您可以在 Cloud Monitoring 信息中心内创建自定义视图和提醒，其中指标自动可用。
Bigtable Key Visualizer 是 Google Cloud 控制台中的一项监控功能，让您可以执行高级性能调整。
IAM 和安全性
在 Bigtable 中，授权完全集成到 Google Cloud 的 IAM 框架中，并且只需进行极少的设置和维护。本地用户账号和密码不会与客户端应用共享；相反，系统会向组织级别用户和服务账号授予细化的权限和角色。
Bigtable 会自动加密静态数据和传输中的所有数据。没用停用这些功能的选项。所有管理访问权限都会被完整记录。您可以使用 VPC Service Controls 控制从已批准的网络外部对 Bigtable 实例的访问。
后续步骤
- 了解 Bigtable 架构设计。
- 试用面向 Cassandra 用户的 Bigtable Codelab。
- 了解 Bigtable 模拟器。
- 探索有关 Google Cloud 的参考架构、图表和最佳做法。查看我们的 Cloud 架构中心。