另外一个值得一提的是PostgreSQL XC这个项目，其整体的架构有点像早期版本的OceanBase，由一个中央节点来处理协调分布式事务，数据分散在各个存储节点上，应该是目前PG 社区最好的分布式扩展方案，不少人在基于这个项目做自己的系统。
3、NewSQL的发展
2012~2013年Google 相继发表了Spanner和F1两套系统的论文，让业界第一次看到了关系模型和NoSQL的扩展性在一个大规模生产系统上融合的可能性。 Spanner 通过使用硬件设备（GPS时钟+原子钟）巧妙地解决时钟同步的问题，而在分布式系统里，时钟正是最让人头痛的问题。Spanner的强大之处在于即使两个数据中心隔得非常远，也能保证通过TrueTime API获取的时间误差在一个很小的范围内（10ms），并且不需要通讯。Spanner的底层仍然基于分布式文件系统，不过论文里也说是可以未来优化的点。
Google的内部的数据库存储业务，大多是3~5副本，重要的数据需要7副本，且这些副本遍布全球各大洲的数据中心，由于普遍使用了Paxos，延迟是可以缩短到一个可以接受的范围(写入延迟100ms以上)，另外由Paxos带来的Auto-Failover能力，更是让整个集群即使数据中心瘫痪，业务层都是透明无感知的。F1是构建在Spanner之上，对外提供了SQL接口，F1是一个分布式MPP SQL层，其本身并不存储数据，而是将客户端的SQL翻译成对KV的操作，调用Spanner来完成请求。
Spanner和F1的出现标志着第一个NewSQL在生产环境中提供服务，将下面几个功能在一套系统中提供：
SQL支持
ACID事务
水平扩展
Auto Failover
多机房异地容灾
正因为具备如此多的诱人特性，在Google内部，大量的业务已经从原来的 BigTable切换到Spanner之上。相信这对业界的思路会有巨大的影响，就像当年的Hadoop一样，Google的基础软件的技术趋势是走在社区前面的。
Spanner/F1论文引起了社区的广泛的关注，很快开始出现了追随者。第一个团队是CockroachLabs做的CockroachDB。CockroachDB的设计和Spanner很像，但是没有选择TrueTime API ，而是使用HLC（Hybrid logical clock），也就是NTP +逻辑时钟来代替TrueTime时间戳，另外CockroachDB选用Raft做数据复制协议，底层存储落地在RocksDB中，对外的接口选择了PG协议。
CockroachDB的技术选型比较激进，比如依赖了HLC来做事务，时间戳的精确度并没有办法做到10ms内的延迟，所以Commit Wait需要用户自己指定，其选择取决于用户的NTP服务时钟误差，这点对于用户来说非常不友好。当然 CockroachDB的这些技术选择也带来了很好的易用性，所有逻辑都在一个组件中，部署非常简单，这个是非常大的优点。
另一个追随者就是我们做的TiDB。这个项目已经开发了两年时间，当然在开始动手前我们也准备了很长时间。接下来我会介绍一下这个项目。
二、TiDB的架构和最近进展
TiDB本质上是一个更加正统的Spanner和F1实现，并不CockroachDB那样选择将SQL和KV融合，而是像Spanner和F1一样选择分离。
这样分层的思想也是贯穿整个TiDB项目始终的，对于测试，滚动升级以及各层的复杂度控制会比较有优势，另外TiDB选择了MySQL协议和语法的兼容，MySQL社区的ORM框架、运维工具，直接可以应用在TiDB上，另外和 Spanner一样，TiDB是一个无状态的MPP SQL Layer，整个系统的底层是依赖 TiKV 来提供分布式存储和分布式事务的支持，TiKV的分布式事务模型采用的是Google Percolator的模型，但是在此之上做了很多优化，Percolator的优点是去中心化程度非常高，整个继续不需要一个独立的事务管理模块，事务提交状态这些信息其实是均匀分散在系统的各个key的meta中，整个模型唯一依赖的是一个授时服务器，在我们的系统上，极限情况这个授时服务器每秒能分配 400w以上个单调递增的时间戳，大多数情况基本够用了（毕竟有Google量级的场景并不多见），同时在TiKV中，这个授时服务本身是高可用的，也不存在单点故障的问题。
上面是TiKV的架构图。TiKV和CockroachDB一样也是选择了Raft作为整个数据库的基础，不一样的是，TiKV整体采用Rust语言开发，作为一个没有GC和 Runtime的语言，在性能上可以挖掘的潜力会更大。不同TiKV实例上的多个副本一起构成了一个Raft Group，PD负责对副本的位置进行调度，通过配置调度策略，可以保证一个Raft Group的多个副本不会保存在同一台机器/机架/机房中。
除了核心的TiDB、TiKV之外，我们还提供了不少易用的工具，便于用户做数据迁移和备份。比如我们提供的Syncer，不但能将单个MySQL实例中的数据同步到TiDB，还能将多个MySQL实例中的数据汇总到一个TiDB集群中，甚至是将已经分库分表的数据再合库合表。这样数据的同步方式更加灵活好用。