开发/数据库

  |  手机版

收藏网站

投稿QQ:1745232315

IT专家网,汇聚专业声音 解析IT潮流 IT专家网,汇聚专业声音 解析IT潮流

网络

专家视点在现场环球瞭望
IT专家网 > 开发/数据库

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

作者:卢敏出处:论坛2018-09-07 17:04

  关于分布式数据库的过去、现在与未来,你了解多少?今天小编就要为大家介绍一下相关知识。

  一、分布式数据库的历史和现状

  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一样,并不支持跨行事务,所以在Google内部有团队开发了MegaStore、Percolator这些基于BigTable的事务层。Jeff Dean承认很后悔没有在BigTable中加入跨行事务,这也是Spanner出现的一个原因。

  (2)RDMS的救赎

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

  国内开发者在这个领域有过很多的著名的项目,比如阿里的Cobar、TDDL,后来社区基于Cobar改进的MyCAT,360开源的Atlas等,都属于这一类中间件产品。在中间件这个方案上有一个知名的开源项目是Youtube的Vitess,这是一个集大成的中间件产品,内置了热数据缓存、水平动态分片、读写分离等,但这也造成了整个项目非常复杂。

  另外一个值得一提的是PostgreSQL XC这个项目,其整体的架构有点像早期版本的OceanBase,由一个中央节点来处理协调分布式事务,数据分散在各个存储节点上,应该是目前PG 社区最好的分布式扩展方案,不少人在基于这个项目做自己的系统。

  3、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的出现标志着第一个NewSQL在生产环境中提供服务,将下面几个功能在一套系统中提供:

  SQL支持

  ACID事务

  水平扩展

  Auto Failover

  多机房异地容灾

  正因为具备如此多的诱人特性,在Google内部,大量的业务已经从原来的 BigTable切换到Spanner之上。相信这对业界的思路会有巨大的影响,就像当年的Hadoop一样,Google的基础软件的技术趋势是走在社区前面的。

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

  CockroachDB的技术选型比较激进,比如依赖了HLC来做事务,时间戳的精确度并没有办法做到10ms内的延迟,所以Commit Wait需要用户自己指定,其选择取决于用户的NTP服务时钟误差,这点对于用户来说非常不友好。当然 CockroachDB的这些技术选择也带来了很好的易用性,所有逻辑都在一个组件中,部署非常简单,这个是非常大的优点。

  另一个追随者就是我们做的TiDB。这个项目已经开发了两年时间,当然在开始动手前我们也准备了很长时间。接下来我会介绍一下这个项目。

相关文章

关键词:分布式数据库,数据库

责任编辑:林音子

网警备案