细说分布式数据库的过去、现在与未来细说分布式数据库的过去、现在与未来
随着大数据这个概念的兴起以及真实需求在各个行业的落地,很多人都热衷于讨论分布式数据库,今天就这个话题,主要分为
三部分:第一部分讲一下分布式数据库的过去和现状,希望大家能对这个领域有一个全面的了解;第二部分讲一下TiDB的架构
以及最近的一些进展;最后结合我们开发TiDB过程中的一些思考讲一下分布式数据库未来可能的趋势。
一、分布式数据库的历史和现状
1、从单机数据库说起
关系型数据库起源自1970年代,其最基本的功能有两个:
把数据存下来;
满足用户对数据的计算需求。
第一点是最基本的要求,如果一个数据库没办法把数据安全完整存下来,那么后续的任何功能都没有意义。当满足第一点后,
用户紧接着就会要求能够使用数据,可能是简单的查询,比如按照某个Key来查找Value;也可能是复杂的查询,比如要对数据
做复杂的聚合操作、连表操作、分组操作。往往第二点是一个比第一点更难满足的需求。
在数据库发展早期阶段,这两个需求其实不难满足,比如有很多优秀的商业数据库产品,如Oracle/DB2。在1990年之后,出
现了开源数据库MySQL和PostgreSQL。这些数据库不断地提升单机实例性能,再加上遵循摩尔定律的硬件提升速度,往往能
够很好地支撑业务发展。
接下来,随着互联网的不断普及特别是移动互联网的兴起,数据规模爆炸式增长,而硬件这些年的进步速度却在逐渐减慢,人
们也在担心摩尔定律会失效。在此消彼长的情况下,单机数据库越来越难以满足用户需求,即使是将数据保存下来这个最基本
的需求。
2、分布式数据库
所以2005年左右,人们开始探索分布式数据库,带起了NoSQL这波浪潮。这些数据库解决的首要问题是单机上无法保存全部
数据,其中以HBase/Cassadra/MongoDB为代表。为了实现容量的水平扩展,这些数据库往往要放弃事务,或者是只提供简
单的KV接口。存储模型的简化为存储系统的开发带来了便利,但是降低了对业务的支撑。
(1)NoSQL的进击的进击
HBase是其中的典型代表。HBase是Hadoop生态中的重要产品,Google BigTable的开源实现,所以这里先说一下BigTable。
BigTable是Google内部使用的分布式数据库,构建在GFS的基础上,弥补了分布式文件系统对于小对象的插入、更新、随机
读请求的缺陷。HBase也按照这个架构实现,底层基于HDFS。HBase本身并不实际存储数据,持久化的日志和SST file存储
在HDFS上,Region Server通过 MemTable 提供快速的查询,写入都是先写日志,后台进行Compact,将随机写转换为顺序
写。数据通过 Region 在逻辑上进行分割,负载均衡通过调节各个Region Server负责的Region区间实现,Region在持续写入
后,会进行分裂,然后被负载均衡策略调度到多个Region Server上。
前面提到了,HBase本身并不存储数据,这里的Region仅是逻辑上的概念,数据还是以文件的形式存储在HDFS上,HBase并
不关心副本个数、位置以及水平扩展问题,这些都依赖于HDFS实现。和BigTable一样,HBase提供行级的一致性,从CAP理
论的角度来看,它是一个CP的系统,并且没有更进一步提供 ACID 的跨行事务,也是很遗憾。
HBase的优势在于通过扩展Region Server可以几乎线性提升系统的吞吐,及HDFS本身就具有的水平扩展能力,且整个系统
成熟稳定。但HBase依然有一些不足。首先,Hadoop使用Java开发,GC延迟是一个无法避免问题,这对系统的延迟造成一
些影响。另外,由于HBase本身并不存储数据,和HDFS之间的交互会多一层性能损耗。第三,HBase和BigTable一样,并不