分布式存储-从单机到多机概述 part 2

今天双11  作为DRDS(TDDL) 和ONS(Notify/MetaQ)的负责人 ，其实还是有点压力的，于是我决定化压力为动力，更新一篇~

今天我们来讲讲分布式存储领域的各类名词的发展来源吧~如果您有关注过存储领域，那一定会对这里面的NoSQL,SQL,KV等等专业名词听得是头晕脑胀，在这里我就简单来说说这个体系的发展历程，让大家能有个比较清晰的脉络。

恩 简单理解一下最近这10年的分布式数据库领域的发展历程的话，那么我们可以简单概括如下：

其实就是一帮“牛人”觉得他想明白了数据库

1.  要关系代数模型

2. 要事务支持

怎么才能做到呢？他们决定：

最下层是文件存储。

中间是KV，使用文件存储来提供KV查询支持。

上层是数据库，支持事务和关系代数。

这就是传统的单机数据库的整体架构，在上世纪70年代到本世纪初，单机数据库一直都可以玩的挺好，虽然有些时候容量有点问题，但数据量增长不大，因此只要买个更贵的，更好的数据库，做一些SQL优化也就能够应付了。

结果到了新时代，21世纪了，互联网的蓬勃发展，让每个人都能够成为了信息的发送源头，这就产生了海量的数据，传统的关系数据库厂商发现，自己之前玩的挺好的这套关系模型，在分布式领域却玩不转了。因为网络延迟限制，必须做权衡。

于是就有了各式各样的权衡策略。

首先 分别针对：数据扩展性和ADHOC（任意多维度查询）分出了两种流派

OLTP( DRDS分布式数据库, 类似 MySQL的RDS单机数据库等)用于 处理在线高并发事务场景。

OLAP( DRDS, RDS, Hadoop等)处理离线分析类场景

然后，大家发现原来事务如果只在单机的时候成本很低，但在分布式场景下成本却很高，于是就出现了单机数据库/分布式数据库的分野，单机数据库往外延伸，就是cluster技术，例如mysql cluster，核心思路是只将文件系统做成分布式的，上层还是希望复用单机事务和单机执行计划。这种的劣势就是因为分布式事务和JOIN，都受到网络延迟和吞吐的限制。事务、join能做但都做不好，给用户的感觉是慢，扩展性也一般，显得不伦不类，一直没成气候。

还有一类技术就是做切分，对应 drds , mysql fabric等 。 这条路下来的就放弃了分布式事务，引导用户使用单机事务模型和优良的业务权衡来尽可能规避分布式事务和JOIN，好处是业务做这一次就再也不担心扩展性问题了，性能也非常强力，可以按需扩展，代价就是与传统单机数据库不能完全兼容，需要业务按照分布式系统设计原则进行系统设计。于是，做切分的看不上做cluster的（觉得你那条路走不通），做cluster的也看不上做切分的（觉得你那条路对应用要求太高）。。。

 

然后突然，因为有些人觉得关系模型太慢，所以觉得应该放弃所有关系模型，退回KV存储 ，这就是NoSQL , 对应Hbase,等，一下把上面两类打懵了，但最后所有人都回过味儿来，这东西坑的是应用,带来的好处却不怎么明显，应用就不乐意了，于是NoSQL就风光了1年多，现在已经“回归理性”了。

 

然后又有人觉得KV存储也太重，对于普通文件还要用kv模型不合适，所以有了BigTable ， 对应OSS。 专门存文件优化。

理论上来说关系模型的数据库能够支持一切场景，不过现实总不像理论那么美好：）

所以还是要选择最适合我们的存储模型为好，能单机做的，尽可能不分布式。

人类的美好愿望总是能够保证高性能，低成本，无限制扩展，容易使用和理解。

但~ 容易理解的模型性能都不好，性能好的模型不容易理解，这就是生活--《分布式系统原理与泛型》