对于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语法协议兼容、数据同步、自动化运维的工作。