【TIDB】三、数据库的发展历史、如今、将来
一、从单机数据库提及（Mysql、Oracle、PostgreSQL）
关系型数据库起源自1970年代，其最基本的功能有两个：html
-
把数据存下来； 算法
-
知足用户对数据的计算需求。sql
第一点是最基本的要求，若是一个数据库没办法把数据安全完整存下来，那么后续的任何功能都没有意义。当知足第一点后，用户紧接着就会要求可以使用数据，多是简单的查询，好比按照某个Key来查找Value；也多是复杂的查询，好比要对数据作复杂的聚合操做、连表操做、分组操做。每每第二点是一个比第一点更难知足的需求。数据库
在数据库发展早期阶段，这两个需求其实不难知足，好比有不少优秀的商业数据库产品，如Oracle/DB2。在1990年以后，出现了开源数据库MySQL和PostgreSQL。这些数据库不断地提高单机实例性能，再加上遵循摩尔定律的硬件提高速度，每每可以很好地支撑业务发展。安全
接下来，随着互联网的不断普及特别是移动互联网的兴起，数据规模爆炸式增加，而硬件这些年的进步速度却在逐渐减慢，人们也在担忧摩尔定律会失效。在此消彼长的状况下，单机数据库愈来愈难以知足用户需求，即便是将数据保存下来这个最基本的需求。服务器
二、分布式数据库之Nosql的进击（HBase/Cassadra/MongoDB）
HBase是其中的典型表明。HBase是Hadoop生态中的重要产品，Google BigTable的开源实现。运维
HBase自己并不存储数据，这里的Region仅是逻辑上的概念，数据仍是以文件的形式存储在HDFS上，HBase并不关心副本个数、位置以及水平扩展问题，这些都依赖于HDFS实现。和BigTable同样，HBase提供行级的一致性，从CAP理论的角度来看，它是一个CP的系统，而且没有更进一步提供 ACID 的跨行事务，也是很遗憾。分布式
HBase的优点在于经过扩展Region Server能够几乎线性提高系统的吞吐，及HDFS自己就具备的水平扩展能力，且整个系统成熟稳定。工具
但HBase依然有一些不足oop
- 首先，Hadoop使用Java开发，GC延迟是一个没法避免问题，这对系统的延迟形成一些影响。
- 另外，因为HBase自己并不存储数据，和HDFS之间的交互会多一层性能损耗。
- 第三，HBase和BigTable同样，并不支持跨行事务，因此在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean认可很后悔没有在BigTable中加入跨行事务，这也是Spanner出现的一个缘由。
三、分布式数据库之RDMS的救赎（Cobar、Zebra、Atlas、Vitess）
RDMS系统作了很多努力来适应业务的变化，也就是关系型数据库的中间件和分库分表方案。作一款中间件须要考虑不少，好比解析 SQL，解析出ShardKey，而后根据ShardKey分发请求，再合并结果。另外在中间件这层还须要维护Session及事务状态，并且大多数方案并不支持跨shard的事务。还有动态的扩容缩容和自动的故障恢复，在集群规模愈来愈大的状况下，运维和DDL的复杂度是指数级上升。
四、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的追随者
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的多个副本不会保存在同一台机器/机架/机房中。
六、将来趋势
一、数据库会随着业务云化，将来一切的业务都会跑在云端，无论是私有云或者公有云，运维团队接触的可能不再是真实的物理机，而是一个个隔离的容器或者「计算资源」
二、多租户技术会成为标配，一个大数据库承载一切的业务，数据在底层打通，上层经过权限，容器等技术进行隔离
三、OLAP和OLTP业务会融合，用户将数据存储进去后，须要比较方便高效的方式访问这块数据，可是OLTP和OLAP在SQL优化器/执行器这层的实现必定是千差万别的。以往的实现中，用户每每是经过ETL工具将数据从OLTP数据库同步到OLAP数据库，这一方面形成了资源的浪费，另外一方面也下降了OLAP的实时性。对于用户而言，若是能使用同一套标准的语法和规则来进行数据的读写和分析，会有更好的体验。
四、在将来分布式数据库系统上，主从日志同步这样落后的备份方式会被Multi-Paxos / Raft这样更强的分布式一致性算法替代，人工的数据库运维在管理大规模数据库集群时是不可能的，全部的故障恢复和高可用都将是高度自动化的。
七、知识拓展
7.一、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.二、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