TIDB3数据库的发展历史现在未来

Posted 2022-01-02 wangzhongqiu

1、从单机数据库说起（mysql、Oracle、PostgreSQL）

关系型数据库起源自1970年代，其最基本的功能有两个：

1. 把数据存下来；  

2. 满足用户对数据的计算需求。

第一点是最基本的要求，如果一个数据库没办法把数据安全完整存下来，那么后续的任何功能都没有意义。当满足第一点后，用户紧接着就会要求能够使用数据，可能是简单的查询，比如按照某个Key来查找Value；也可能是复杂的查询，比如要对数据做复杂的聚合操作、连表操作、分组操作。往往第二点是一个比第一点更难满足的需求。

在数据库发展早期阶段，这两个需求其实不难满足，比如有很多优秀的商业数据库产品，如Oracle/DB2。在1990年之后，出现了开源数据库MySQL和PostgreSQL。这些数据库不断地提升单机实例性能，再加上遵循摩尔定律的硬件提升速度，往往能够很好地支撑业务发展。

接下来，随着互联网的不断普及特别是移动互联网的兴起，数据规模爆炸式增长，而硬件这些年的进步速度却在逐渐减慢，人们也在担心摩尔定律会失效。在此消彼长的情况下，单机数据库越来越难以满足用户需求，即使是将数据保存下来这个最基本的需求。

2、分布式数据库之Nosql的进击（HBase/Cassadra/MongoDB）

HBase是其中的典型代表。HBase是Hadoop生态中的重要产品，Google BigTable的开源实现。

HBase本身并不存储数据，这里的Region仅是逻辑上的概念，数据还是以文件的形式存储在HDFS上，HBase并不关心副本个数、位置以及水平扩展问题，这些都依赖于HDFS实现。和BigTable一样，HBase提供行级的一致性，从CAP理论的角度来看，它是一个CP的系统，并且没有更进一步提供 ACID 的跨行事务，也是很遗憾。

HBase的优势在于通过扩展Region Server可以几乎线性提升系统的吞吐，及HDFS本身就具有的水平扩展能力，且整个系统成熟稳定。

但HBase依然有一些不足

• 首先，Hadoop使用Java开发，GC延迟是一个无法避免问题，这对系统的延迟造成一些影响。
• 另外，由于HBase本身并不存储数据，和HDFS之间的交互会多一层性能损耗。
• 第三，HBase和BigTable一样，并不支持跨行事务，所以在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean承认很后悔没有在BigTable中加入跨行事务，这也是Spanner出现的一个原因。

3、分布式数据库之RDMS的救赎（Cobar、Zebra、Atlas、Vitess）

RDMS系统做了不少努力来适应业务的变化，也就是关系型数据库的中间件和分库分表方案。做一款中间件需要考虑很多，比如解析 SQL，解析出ShardKey，然后根据ShardKey分发请求，再合并结果。另外在中间件这层还需要维护Session及事务状态，而且大多数方案并不支持跨shard的事务。还有动态的扩容缩容和自动的故障恢复，在集群规模越来越大的情况下，运维和DDL的复杂度是指数级上升。

4、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来完成请求。

5、Spanner和F1的追随者

Spanner/F1论文引起了社区的广泛的关注，很快开始出现了追随者。第一个团队是CockroachLabs做的CockroachDB。CockroachDB的设计和Spanner很像，但是没有选择TrueTime API ，而是使用HLC（Hybrid logical clock），也就是NTP +逻辑时钟来代替TrueTime时间戳，另外CockroachDB选用Raft做数据复制协议，底层存储落地在RocksDB中，对外的接口选择了PG协议。

另一个追随者就是我们做的TiDB。TiDB本质上是一个更加正统的Spanner和F1实现，并不CockroachDB那样选择将SQL和KV融合，而是像Spanner和F1一样选择分离。

和 Spanner一样，TiDB是一个无状态的MPP SQL Layer，整个系统的底层是依赖 TiKV 来提供分布式存储和分布式事务的支持，TiKV的分布式事务模型采用的是Google Percolator的模型，但是在此之上做了很多优化，Percolator的优点是去中心化程度非常高，整个继续不需要一个独立的事务管理模块，事务提交状态这些信息其实是均匀分散在系统的各个key的meta中，整个模型唯一依赖的是一个授时服务器，在我们的系统上，极限情况这个授时服务器每秒能分配 400w以上个单调递增的时间戳，大多数情况基本够用了（毕竟有Google量级的场景并不多见），同时在TiKV中，这个授时服务本身是高可用的，也不存在单点故障的问题。

TiKV和CockroachDB一样也是选择了Raft作为整个数据库的基础，不一样的是，TiKV整体采用Rust语言开发，作为一个没有GC和 Runtime的语言，在性能上可以挖掘的潜力会更大。不同TiKV实例上的多个副本一起构成了一个Raft Group，PD负责对副本的位置进行调度，通过配置调度策略，可以保证一个Raft Group的多个副本不会保存在同一台机器/机架/机房中。

 6、未来趋势

1、数据库会随着业务云化，未来一切的业务都会跑在云端，不管是私有云或者公有云，运维团队接触的可能再也不是真实的物理机，而是一个个隔离的容器或者「计算资源」

2、多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层通过权限，容器等技术进行隔离

3、OLAP和OLTP业务会融合，用户将数据存储进去后，需要比较方便高效的方式访问这块数据，但是OLTP和OLAP在SQL优化器/执行器这层的实现一定是千差万别的。以往的实现中，用户往往是通过ETL工具将数据从OLTP数据库同步到OLAP数据库，这一方面造成了资源的浪费，另一方面也降低了OLAP的实时性。对于用户而言，如果能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。

4、在未来分布式数据库系统上，主从日志同步这样落后的备份方式会被Multi-Paxos / Raft这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，所有的故障恢复和高可用都将是高度自动化的。

7、知识拓展

7.1、GPS同步时钟工作原理

在最初的同步通信系统中，我们会找到一个时钟源，然后把所有的收发子系统都接到这个时钟源上。小型的同步通信系统完全可以这样做，比如一台电脑中的一个同步通信的系统，他们就用电缆线接到一个共同的时钟源上，再来收发信号。

可是一旦同步通信的系统变大到全国性的呢？如果还用电缆或者光缆接到同一个时钟源上，会发生很多问题。首先，建设的成本太大了，要在全国范围内铺设线路，只为传输一个时钟信号，不划算。其次，如果收发信机分别在黑龙江和广东，时钟信号即使以光速传过去，还会产生一定的延时。

每个GPS卫星上都有2~3个高精度的原子钟，这几块原子钟互为备份的同时，也互相纠正。另外地面的控制站会定期发送时钟信号，和每一颗卫星进行时钟校准。 

当然你可能会担心卫星信号传送到地面的延迟问题。GPS信号中自带了误差纠正码，接收端可以很容易的把延迟的这段传输延迟去掉。另外，由于卫星信号很微弱，只有在室外才能接受的到，因此每个GPS授时系统都应当有室外天线，否则就不能用了。

这样一来上面列出的两个问题都解决了。用来铺设全国性电缆并不是每家公司都有资金实力的，而且铺设的成本用来买GPS接收器，那肯定可以买到无数个了。而延时的问题，也被GPS出色的编码系统所解决了。真的是太完美了。

Spanner是如何保证每个事务最后得到的commit timestamp介于这个事务的start和commit之间？

在事务开始阶段调用一次TrueTime，返回[t-ε1,t1+ε1]，在事务commit阶段时再调用一次TrueTime,返回[t2-ε2,t2+ε2]，根据TrueTime的定义，显然，只要t1+ε1<t2-ε2，那么commit timestamp肯定位于start和commit之间。等待的时间大概为2ε，大约14ms左右。可以说，这个延时基本上还可以接受。

7.2、Hybrid Logical Clock(HLC)

每个Cockroach节点都维持了一个混合逻辑时钟(HLC) ，相关的论文见 HybridLogical Clock paper。HLC时间使用的时间戳由一个物理部件（看作总是接近本地物理时钟）和一个逻辑部件（用于区分相同物理部件上的事件）组成。它使我们能够以较少的开销跟踪相关联事件的因果性，类似于向量时钟（译注：vector clock，可参考Leslie Lamport在1978年发表的一篇论文《Time, Clocks, and the Ordering of Events in aDistributed System》）。在实践中，它工作起来更像一个逻辑时钟：当一个节点收到事件时，它通知本地逻辑HLC由发送者提供的事件时间戳，而当事件被发送时会附加一个由本地HLC生成的时间戳。

Cockroach使用HLC时间为事务选取时间戳。本文中，所有 时间戳 都是指HLC时间，HLC时钟在每个节点上是都是单一实例的（译注：也就是说每个节点上只有唯一一个HLC时钟，不会有两个时钟，产生两个时间的问题）。HLC时钟由节点上的每个读/写事件来更新，并且HLC 时间大于等于（ >= ）系统时间（wall time）。从来自其他节点的Cockroach请求里接收到的读/写时间戳不仅仅用来标识操作的版本，也会更新本节点上的HLC时钟。这用于保证在一个节点上的所有数据读写时间戳都小于下一次HLC时间。

 

 

 

参考：

https://www.oschina.net/news/84386/about-distributed-database?utm_source=tuicool

https://www.syn029.com/h-nd-489.html?groupId=-1