总结一下对关系型数据库变化粗浅的认识。
前言
第一次知道数据库，是在大学时的数据库课程，那个时候的数据库特指关系型数据库。到后面工作后，才知道除了MySQL，Oralce这类关系数据库之外，还有NoSQL。
印象中，当时NoSQL由于优秀的性能和扩展性，发展迅速。但技术并非一成不变，二者可以相互借鉴。
待NoSQL潮水褪去，NewSQL出现，就像是是NoSQL和SQL在易用性和可扩展性上的平衡。
技术线
关系型数据库的特点
1.SQL。
2. 事务，符合ACID原则。
3. 结构化存储。
这些特点的关键，就是易用性。
比如世界上使用最多的数据库SQLite，常用于手机App的本地存储。它就是一个lib库，小巧而精悍。但也支持上述的特点。因此也是一款关系型数据库。
可用性需求
主备同步的优化
MySQL，PostgreSQL，都是流行的数据库之一，它们广泛用于在线交易，或近线计算中。它们都有主备同步的方案。
默认方案
比如MySQL基于Binlog同步数据，有异步同步和半同步，通常使用外部高可用组件来控制流量。 但由于binog并非强同步，所以主库彻底挂掉的情况下，会存在丢数据的风险。 PostgreSQL可以强同步，但同样存在问题，备库异常会影响主库可用性。
引入分布式共识
可用性和一致性无法两全其美，但可以尽可能的优化。比如使用3个节点，相比2节点强同步，能达到同等一致性，也有更好的可用性。
使用分布式共识算法来同步日志是目前的标准做法，类似Spanner，TiDB,OceanBase等NewSQL也都是基于分布式共识算法来保证数据的一致性。
使用Mulit-Paxos算法的产品
传统数据库: AliSQL X-Cluster，TDSQL，MySQL Group Replication NewSQL: Spanner，Oceanbase
使用Raft算法的数据库
Tidb,CockroachDB
两种算法各有千秋。
更大的吞吐能力
当单台服务器的资源不足以支撑数据库的需求时，我们需要进行扩容，提升资源。
1. ScaleUp: 提升单机的性能，比如使用更好的CPU,更大的内存，更大更快的SSD存储。
2. ScaleOut: 使用更多的服务器。
硬件提升终归有限，所以ScaleOut是最后的办法。目前，ScaleOut有两种Shared-Nothing,Shared-Disk.
Shared-Disk
在这个方向，有一个优化思路是将本地存储使用分布式存储替换。 1. 适合容量非常大，但写较少的场景。 2. 完全兼容单机数据库。 2. 缺点则是只解决了存储瓶颈，并没有解决计算和内存的瓶颈。
使用这种方案最经典的产品是
1. Oracle RAC，使用专用存储，应该是比较费钱。
2. Amazon Aurora/PolarDB MySQL，改造了Innodb,使用分布式存储的方式存储文件。
3. OceanBase0.5,最早的OceanBase,ChunkServer其实就是分布式存储，UpdateServer则是单点的修改入口。因此当时的结构，更像是Shared-Disk的设计。
4. 使用虚拟机运行数据库也是个不错的办法，因为云上的分布式存储本身就具备很高的可用性，比如直接将数据库跑在使用云盘的ECS上，也差不多可以达到这个效果。较好的云盘，可能也会使用RDMA，NVME等技术。搭车很不错。
Shared-Nothing
使用分布式集群的方式来提升系统容量。简单说，就是将请求分散到多台服务器上处理。
分布式中间件
分布式中间件是在NewSQL出现前，最常用的解决办法。
关键功能
- 分库分表访问
- 全局Sequence，全局递增但不一定连续。
- 小表广播
- 全局索引
几个分布式中间件
Taobao Distributed Data Layer,淘宝分布式中间件，外号头都大了。是基于客户端实现的中间件，没有Proxy，承担淘宝很多核心的数据库访问。MariaDB MaxScale/Spider,开源的Proxy式中间件，基于MySQL内核实现。
分布式中间件具备了一定分布式的能力，但依然有很多限制，但已经非常接近NewSQL了。 有的NewSQL产品就是分布式中间件的实现。
分布式事务的需求
在解决了上面的各种问题之后，NewSQL还要解决的问题就是分布式事务。
比如常见的交易系统实现，我们可以使用中间件来做分库分表，达到很快的订单创建。订单创建同时，我们需要扣减库存，需要扣款。这些动作分布式中间件不能支持事务，通常需要另一个中间件来实现分布式事务。
因为事务的实现并不能简单的在中间件层面完成，也涉及存储。分布式事务需要全局时钟,2PC和MVCC配合实现。
NewSQL
NewSQL是上述特点的集大成者。
1. 原始数据库的特性。
2. 基于分布式共识的多副本同步。
3. 分库分表技术。
4. 分布式事务。
在NewSQL的实现中，有部分基于现有的数据库和中间件。有部分借鉴Spanner,使用KV存储上增加SQL解析层。但也是大同小异。
几款NewSQL
Spanner/F1,基于truetime的数据库。也只有这样，才能实现全球化部署。其它基于中央授时，或逻辑时钟的关系型数据库，都无法做到全球化部署生产。TiDB/TiKV,Spanner/F1，的乞丐版实现，由于使用了TSO所以集群通常不会跨城市。此外，事务的实现是在TiDB上，和Spanner略有不同。但事务隔离性强于Spanner,可能是因为不用考虑truetime的延时.Ocaenbase,蚂蚁金服的分布式数据库，于TiDB/TiKV不同，KV层和SQL层不做分离。
总结
技术的发展总归不是一蹴而就，而是一步步变化的，是易用性和业务需求的相互作用。
1. 最早的关系型数据库，是易用性占主导地位。
2. NoSQL崛起，则是更高性能的业务需求占主导地位。
3. 随着硬件提升和技术发展，重新回归SQL的NewSQL，则是易用性重新占据主导地位。
