开源NewSQL – CockroachDB在百度内部的应用与实践

内容来源：2017 年 11 月 18 日，百度数据库架构师严龙在“第七届数据技术嘉年华”进行《百度NewSQL-CockroachDB》演讲分享。IT 大咖说（微信id：itdakashuo）做为独家视频合做方，经主办方、演讲者以及微信公众号——CockroachDB（微信id：CockroachDB）审阅受权发布。

阅读字数：3621 | 10分钟阅读

嘉宾演讲视频及PPT回顾： suo.im/5bnORh

摘要

本次交流主要包括开源 NewSQL 数据库 Cockroach DB 关键技术分析以及 Cockroach DB 在百度内部的应用和实践。

NewSQL起源

对于MySQL、Oracle、PostgreSQL这样的单机数据库，随着数据量的增加在计算容量和存储容量上都会出现问题。因而后续又推出了基于中间件或者NoSQL的方案，可是都并不是完美，好比中间件在分布式事务方面以及NoSQL在SQL接口和对事务的支持方面作了必定退让。

2011年分析师Matthew Aslett首次提出了NewSQL的概念，指望将NoSQL和传统的数据库的优点融合，将现有数据库存在的缺陷在下一代中解决掉。而Google首先将这一律念工程化，也就是Spanner。随后开源社区也陆续跟进。

Cockroach DB简介

Cockroach DB于2014年托管在GitHub，遵循Apache License，基于Golang实现。 Star数量12000+，Contributor数量150+。当前2.0.1版本。母公司是Cockroach Labs，公司的三位创始人所有来自Google，有Big Table，GFS，Colossus，Gmail项目背景，已得到来自Benchmark，Google Venture等共计5325万的融资。总部位于纽约，目前有50+员工。

Cockroach DB架构

Cockroach DB采用相似Spanner的分层架构，在分布式KV上提供了SQL引擎，分布式KV之下引入了自身独有三个概念Node、Store、Range。

Node & Store

Node是Cockroach DB的进程实例，一台物理服务器启动一个Node便可，一个物理存储介质（例如一块硬盘）通常配置一个Store，一个Node中有多个Store。

Range

Range是Cockroach DB存储管理的最小单位，一个Range是一段键值区间的数据分片。一个Store中有多个Range，每一个Range分片默认为64M，默认存在3个副本，分布在不一样的Node上。

ockroach DB特性

标准SQL接口

Cockroach DB使用PostgreSQL协议，支持标准SQL接口，兼容关系型数据库SQL生态。支持事务、二级索引、Join等NoSQL欠缺的特性，同时还供了类MPP的分布式查询框架。它还支持Schema在线变动，以方便应对业务的变化。

SQL & KV

因为Cockroach DB底层是分布式KV，那么必然就要将全部的SQL操做转换为KV操做。因而它就在底层抽象出了Get、Put、ConditionalPut、Scan、Del这五个KV做原语。

SQL / KV模型映射

解决完KV操做的问题后，还有另外一个问题有待解决，即Schema到KV模型的映射。Cockroach DB的每一个表都须要有一个Primary Key，每一列（不是每行）构成一个Key / Value存储单元，Key由<db>、<table>、<index>、<pkey>、<columnld>这几部分共同构成。

惟一索引

在KV存储中必须保证key全局惟一，这样就能方便前缀匹配。Cockroach DB为了实现惟一索引，首先会将<db>、<table>、<index>、<key>编码到Key中，当作索引扫描时就要进行前缀匹配，而后就能将相应的Value取出来。这里因为<key>是全局惟一的因此索引的惟一性也得以保证。

非惟一索引

对于非惟一索引Cockroach DB处理就比较巧妙了，它将行的<pkey>也编译到了Key中，这样对索引作前缀匹配时，只要相关的索引项匹配到index前面，就能将相应的<pKey>取出来，而后经过<pkey>反向索引到数据。

Column Family

在行存系统中数据的更新只须要进行一次IO操做，可是因为Cockroach DB是列存的，数据在更新时要进行屡次IO。为此Cockroach DB提出了column family的概念，将须要被频繁访问的列封装到一块儿，甚至能够经过column family的方式退化到行存的方式，这样就能有效减小IO操做。

扩展能力强、高并发

为了实现线性扩展的能力，Cockroach DB采用了去中心化的架构，任意节点故障对于集群无影响。它经过Gossip协议实现节点状态管理，理论上单集群支持10K节点规模。两级路由元数据的方式使得单集群最大支撑4EB用户数据存储。整个架构中子模型都采用分布式设计，无单点瓶颈，支持多节点并发写入。

弹性伸缩

面对单机数据库扩展性的问题，通常采用哈希的数据分布方式。可是除非是使用的是一致性哈希，不然普通的哈希分布都须要有数据迁移和停服的过程。而Cockroach DB选择的是Range分布，在进行扩容时无需停服，直接能够在线扩展，同时由于每一个数据都被划分为64M的小分片，因此在新节点加入时能作到业务无感知的自动负载均衡多副本强一致性。

MySQL数据同步采用的主从复制架构是弱一致性的，而Cockroach DB的副本数据同步是基于Raft协议，具备强一致性，不会出现当某个节点挂了同时redolog尚未彻底复制到从库上致使数据丢失的问题。

服务高可用

Cockroach DB因为架构上去中心化，没有SPDF，因此架构不存在相似Hbase HMaster和Percolator oracle等集中模块，单节点故障也不影响集群群体的可用性。

另外由于基于Raft协议，因此只要半数以上副本存活，则服务可用；当节点异常，数据副本数量少于指定阈值时，自动补齐副本，保证可靠性。

分布式事务

2PC

Cockroach DB使用的是改造过的两阶段提交事务，它引入全局事务表记录事务状态，事务提交/回滚只修改记录的标记位。事务中写入的数据被封装成特殊结构（INTENT），这个INTENT中隐含着索引信息能够反向索引事务状态。这种事务处理模型的好处在于事务提交、回滚开销比较小。

1PC

当全部的事务都是写在一个Range上时，能够利用Raft保证原子性，一次完成数据写入。同时可以优化非跨Range写事务性能，减小RPC通讯。

MVCC

Cockroach DB使用MVCC的并发控制模式，它以HLC时间做版本号，逆序存储保证最新版本数据优先被访问。支持Time-Travel Query，多版本数据由异步GC清理。

HLC算法

HLC算综合借鉴了Physical Clock和Logical Clock思想。HLC Timestamp ID由时间和逻辑时间两部分组成，物理时间经过NTP同步。在发送消息、产生本地事件和接收到消息时，I、J都会被重置为几个参考值中的最大值。这样消除了单点时钟逆变或不一样节点间时钟偏差的影响。

与True Time时钟算法比较

HCL算法实现简单、成本低，有必定时延。它基于NTP时钟服务，不须要额外的硬件，算法简单，实现成本低。不过存在时钟误差，广域网状况下误差范围会比较大。

True Time时钟算法有必定成本、时延低。它基于GPS+原子钟等特殊硬件，实现成本较高。本质上相似Physical clock时钟算法，以一个偏差区间来替代时刻点。True Time时钟系统精度远远高于NTP，可将时延控制在14ms内。

典型应用场景

Cockroach DB比较适合OLTP场景，同时支持轻量级别OLAP场景。这些场景有以下特色：

- 高并发读写，支持多点写入，自动负载均衡

- 大数据量存储

- 随时按需扩展、在线扩容

- 跨数据中心容灾，多副本数据强一致

- 时延要求不苛刻

应用案例

在以前百度内部是经过中间件的方式作数据的分片，可是当要扛峰值流量时就要预先扩容。并且在业务层作数据访问时，必须按照固定的规则才能访问数据，不能跨片作分布式事务。

在引入Cockroach DB以后咱们就能对业务提供统一的数据库视图，使用起来也更简单，更易于运维。

在引入Cockroach DB以前咱们还作了MySQL语法协议兼容、数据同步、自动化运维的工做。

Cockroach官方网站：http://www.cockroachchina.cn/