有趣的灵魂！解析百度云CRDB四大特性

好看的皮囊千篇一律，有趣的灵魂万里挑一。

上月，百度云宣布与著名开源NewSQL数据库公司 Cockroach Labs达成深度战略合作，推出了全新NewSQL云数据库服务CRDB。自CRDB服务上线以来，获得了大批测试用户的一致好评。

百度云CRDB作为一款非常优秀的全球分布式数据库，基于目前最热的开源数据库项目CockroachDB，拥有去中心化架构、跨地域、分布式事务、多副本、强一致性等优点。除了吸纳CockroachDB项目优势外，百度云CRDB还为中国用户的业务场景量身定制，结合实际业务进行优化。

今天，小编要深扒一下百度云CRDB四大特性，对CRDB有趣的数据库灵魂一探究竟。

四大特性铸就有趣的数据库灵魂

百度云CRDB是新一代NewSQL数据库的典型代表，可以为用户提供EB级数据存储、HTAP（OLTP与OLAP融合）、强一致性的分布式事务、无感在线弹性扩容、异地多活和自动数据重分布能力，并兼容PostgreSQL和MySQL语法等多种特性。此外，百度云CRDB还能满足日志、账单类数据等NoSQL类型业务场景。

下面我们重点介绍CRDB四个最重要的特性：

存储能力

高并发能力

低成本

实时分析能力

存储能力

百度云CRDB基于CockroachDB，可以支持EB级的数据存储，能够轻松解决亿级用户数据存储带来的挑战。

CRDB和传统关系型数据库一样，把用户数据以二维表的形式呈现给用户，但底层会将其编码成KV的形式存储，并按照Key范围划分成64MB的一个个数据分片，称之为Range。同时，CRDB使用二级路由的形式管理Range，顶层路由有且只有一个Range，顶层路由记录二级路由的信息，包括位置和Key范围等。二级路由记录每个Range实际的位置和Key范围。

若保持默认大小配置，CRDB最大可存储4EB用户数据。

高并发能力

CRDB采用了去中心化的分布式架构，所有节点在集群中是对等的，任一节点都可以处理客户端请求，并使用P2P协议（GOSSIP）发现、管理节点，每个节点都可以缓存完整的顶层路由数据，从而解决了对顶层路由访问的单点瓶颈。

CRDB实现了一个无锁的，无中心的分布式事务模型。没有中心的事务协调者，采用和Spanner True Time类似的方案，使用HLC时间戳作为事务ID的一部分，所以任一节点都可以创建事务。因为实现的是无锁事务模型，不需要全局锁管理，事务要么执行成功，要么restart或者abort，所以事务冲突可以直接在两个事务发生交集的节点本地处理，不需要第三方仲裁，确保性能接近线性的扩展。

集群的数据会随着用户的增删改操作不断发生变化，如果集群不支持动态调整，那么负载会逐渐向部分节点倾斜，导致集群负载不均。

CRDB目前支持两种模式动态调整集群负载：

一种是基于存储，把数据存储平均到所有节点，保证所有节点的数据量基本保持一致。

另一种是基于状态的均衡模式。系统根据range的负载和数据量决定是否要做分裂，把节点负载也作为数据均衡的考虑因子，来决定是否需要把range迁移到其他节点，分摊负载，整个调整过程对用户无感知。

低成本

CRDB集群组织结构由三层构成：Cluster、Zone和Node。

Cluster是集群，Node是集群中的CRDB实例。Zone是由CockroachDB引入的一个概念，和Google spanner的Directory比较类似。一个Zone由多个具有相同属性的Node组成，在这里我们根据存储类型把集群的节点分成两组Zone：一组是使用SSD或者NVME高速硬盘节点，一组是使用SATA磁盘的低速硬盘节点。

通过对用户的库、表进行Zone存储设置，已有数据按照规则逐步迁移到指定的Zone中，新写入的数据直接按照规则写入指定Zone中。通过Zone Configuration这个特性达到了对冷热数据进行分离，降低存储成本的功能。

当然Zone Configuration特性还可用于跨地域部署时实现用户数据就近访问的功能。

实时分析能力

首先，CRDB选择兼容PostgreSQL协议和语法，能够很好地继承PostgreSQL的生态，能无缝地对接PostgreSQL相关的第三方组件。

其次，CRDB实现了类似MPP数据库的分布式执行引擎，把复杂查询的计算下推到各个节点，让计算并行执行，从而使SQL的计算能力可以随着集群的扩展而得到提升。

CRDB同时支持通过Column Family来达到类似行列混合的效果，适用于不同场景下减少I/O操作，进一步提升查询性能。

与传统数据仓库最大的不同在于，CRDB支持在线分析的同时，仍然能够支持实时更新，让TP、AP融合成为可能。

CRDB的分布式执行引擎目前实现的是Rule Base的优化器，SQL解析之后生成一个类似单机Plan Tree的Logic Plan，由优化器重写之后，进一步结合数据分布的特点生成一个可执行的分布式执行计划Physical Plan。CRDB每一个算子都由单独的goroutine单独调度，通过Mailbox机制协同。因为每一个算子相对比较独立，后续实现SQL挂起和资源隔离也相对容易。