- 数据库中间层
本部分主要是介绍SQL集群化涉及的一些组件，主要包括：proxy、数据节点、agent、元数据节点等，与目前主流分布式存储系统无异。目前基于SQL的分布式数据库，最被诟病的几个问题主要如下：
1. 扩展性差，成倍扩容，甚至需要停止服务一段时间。
2. 单机SQL性能较差，单机吞吐的限制，会导致可用性下降（与引擎相关）。
3. 数据库复制，采用异步方式，可能有数据丢失。
4. 数据迁移，设计大量的数据复制，性能更是不理想（与引擎相关）。
- Microsoft SQL Azure
Azure SQL 对事物的支持与Megastore中实体组类似，只有同机器且相关的数据才能事物，但是由于单机引擎仍然是SQL引擎，性能依然是槽点。分片内采用NWR实现一致性，包括全局分区管理器（记录元数据）亦是。
- Google Spanner
特点
支持外部一致性，跨数据中心的事务。
数据模型
类似Megastore的实体组，每个用户的数据存储已在一个“目录”内。目录是Spanner的最小管理单元（负载均衡等）。一个表顺序的划分为多个子表，一个子表包含做个目录。
架构
物理概念：Universe（一个Spanner实例）、Zones（一个zonde属于一个数据中心，一个数据中心可以多个zone，标准是网络通信，同一个zone内网络代价较小）。
组件：Universe Master（zone级别的状态信息）、Placement Driver（跨zone的数据迁移）
、Location Proxy、Spanserver。
元信息：目录与节点的映射关系，可能存储在元数据表中。
复制与一致性
Spanserver底层是Colossus文件系统（与GFS相比，支持海量小文件，且实时性更好），每个数据中心一套Colossus。子表内分片间采用Paxos协议保持一致性。同机内（Paxos组内），通过锁表实现并发控制，跨机（Paxos组间），绕过锁表，主副本充当事务协调器，通过2PC实现跨Paxos的事务。
TrueTime
GPS + 原子钟的方式，实现系统内全局时钟的一致性。TrueTime API结构返回时间戳 + 误差。
事务及并发控制
不考虑TrueTime：即TrueTime API返回的时间戳认为准确，忽略误差。
Pasox组内读写事务：获取系统时间戳作为版本号，进行读写事务逻辑。
Pasox组内只读事务：获取系统时间戳作为版本号，返回比这个版本号小的数据。
Pasox组内快照读：版本号根据客户端参数设置，返回比这个版本号小的数据。
Pasox组间读写事务：主Pasox充当协调者，向其他Paxos的主副本发送Perpare消息，锁定数据，等待确认后发送Commit消息，提交逻辑，并释放数据。
Pasox组间只读事务：返回比版本号小的数据，防止读到不完整的数据（即另一个进行中的事务涉及到读的数据），等待一个时间待其他事务完成，否则回滚。
考虑TrueTime：考虑TrueTime API返回的误差，严格保证事务提交的数据，相对复杂。
数据迁移
- 总结
本章分布式数据库，显示改造传统单机SQL到集群化介绍涉及的中间，再到Azure SQL，都是基于传统的数据库引擎，由于其性能、扩展性等问题已经很少被使用了，并且设计到的中间件与分布式存储的组件十分相似，故本文章笔记较少。
Spanner作为跨时代的产品，引起了NeWSQL的浪潮，目前各大公司纷纷开始自研相关产品来更好的支持业务发展。主要的包括，阿狸的OcenBase、XDB（据报道XDB将替代OceaBase，内部已经停止OceanBase的更新和新业务上线了）、开源的CockRoachDB（目前百度有一批commiter参与其中，较为活跃）。