分布式数据库的过去、现在与未来.doc

分布式数据库的过去、现在与未来 随着现在时代发展大数据也开始在每个行业中流行。而越来越多人开始喜欢上了分布式数据库，而今天我们也就来讨论下分布式数据库，主要分成三部分第一部分讲一下分布式数据库的过去和现状，希望大家能对这个领域有一个全面的了解;第二部分讲一下TiDB的架构以及最近的一些进展;最后结合我们开发TiDB过程中的一些思考讲一下分布式数据库未来可能的趋势。 一、分布式数据库的历史和现状 1、从单机数据库说起 关系型数据库起源自1970年代，其最基本的功能有两个： 把数据存下来; 满足用户对数据的计算需求。 第一点是最基本的要求，如果一个数据库没办法把数据安全完整存下来，那么后续的任何功能都没有意义。当满足第一点后，用户紧接着就会要求能够使用数据，可能是简单的查询，比如按照某个Key来查找Value;也可能是复杂的查询，比如要对数据做复杂的聚合操作、连表操作、分组操作。往往第二点是一个比第一点更难满足的需求。 在数据库发展早期阶段，这两个需求其实不难满足，比如有很多优秀的商业数据库产品，如Oracle/DB2。在1990年之后，出现了开源数据库MySQL和PostgreSQL。这些数据库不断地提升单机实例性能，再加上遵循摩尔定律的硬件提升速度，往往能够很好地支撑业务发展。 接下来，随着互联网的不断普及特别是移动互联网的兴起，数据规模爆炸式增长，而硬件这些年的进步速度却在逐渐减慢，人们也在担心摩尔定律会失效。在此消彼长的情况下，单机数据库越来越难以满足用户需求，即使是将数据保存下来这个最基本的需求。 2、分布式数据库 所以2016年左右，人们开始探索分布式数据库，带起了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一样，并不支持跨行事务，所以在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean承认很后悔没有在BigTable中加入跨行事务，这也是Spanner出现的一个原因。 (2)RDMS的救赎 除了NoSQL之外，RDMS系统也做了不少努力来适应业务的变化，也就是关系型数据库的中间件和分库分表方案。做一款中间件需要考虑很多，比如解析 SQL，解析出ShardKey，然后根据ShardKey分发请求，再合并结果。另外在中间件这层还需要维护Session及事务状态，而且大多数方案并不支持跨shard的事务，这就不可避免地导致了业务使用起来会比较麻烦，需要自己维护事务状态。此外，还有动态的扩容缩容和自动的故障恢复，在集群规模