PostgreSQL：分布式数据库简史

​首先来一张大图给大家展示下数据库的进化历史，本篇文章会基于下面这个图展开 

图片

数据管理技术的产生和发展

聊分布式数据库之前，先看看数据库的由来。我对数据库的最初认知来自于大学所学的一本书籍《数据库系统概论》(王珊 萨师煊版本)，下面开始聊聊数据管理。

• 人工管理数据 20世纪50年之前，数据靠存储在纸带、卡片、磁带上。这样的数据一般都是用于科学计算，数据一般不需要长期保存，一般都是有程序员来设计、管理和应用数据，数据有变更，程序员也需要调整代码去适配程序，数据强耦合程序。
• 文件系统管理数据 20世纪50～60年代，已经有磁盘可以来存取数据了，并且有了数据模型来存储数据，最早有层次模型和网状模型，层次模型很好的解决了 1 V 1 和 1 V N的关系，层面简单清晰、查询效率高，但是对于N V 1（多对1的实现比较困难）；网状模型很好的描述了各种对应关系，缺点就是结构复杂，不容易实现。
• 关系数据模型的诞生和数据库发展 20世纪70年代，IBM公司研究员E.F.Code首次提出了关系模型，这个人很伟大，开创了关系型数据库的盛世，有人会问，啥是关系模型？关系模型就是一张规范化的二维表(不明白的可以从自家的mysql数据库里select * from table limit 100)，并且涉及到很多沿用至今的DBA们耳熟能详的：表名、元组、属性、键等等。 关系模型很好的解决了各种数据的对应关系，10年后(80年代)，第一批商业化的关系型数据库开始诞生，这里有大家熟知的Oracle、DB2、SQL Server等等，再到90年代，芬兰的一个工程师Michael Widenius(Monty)推出了至今大小厂都在使用的MySQL。MySQL可以说是单机数据库的王者，另外同一时期也有PostgreSQL的诞生，目前也是应用广泛，并且作为其他数据库的底座。2000年后，但是随着数据量的增加，单机的数据库瓶颈已经不能满足大数据量的需求，这时各种分库分表的方案开始大量涌现，有程序员自己控制sharding逻辑的，有基于中间件方案的等等。

大数据催生分布式数据库的诞生和发展

• 分布式数据库的诞生

谈到分布式不得不提下Google这家伟大的公司，2006年google发了3篇论文，也是被认为的大数据3驾马车：分布式文件系统：GFS；分布式KV存储数据库：Big Table；处理和生成超大数据集的算法模型：MapReduce，这些论文的思想诞生了Hadoop生态，也为分布式数据库做好了基垫，2012年Google又发表了2篇论文，分别是spanner和F1，我觉得如果想搞懂分布式数据库，建议这几篇论文都看看，看过论文的都知道，spanner讲的主要是如何基于全局事务时间戳实现事务的MVCC，并且可伸缩、同步多副本的全球化分布式数据库。F1作为一个DBMS之前作为mysql的前端提供数据服务，支持ACID，支持SQL，但是由于每次需要手动拆分MySQL的数据，后来F1将spanner作为自己的下游提供丝滑的扩容和数据自动重分布。

有了这些理论的支撑，产生了大量的分布式nosql和分布式关系数据库。

• 分布式数据库要素 分布式数据库是用计算机网络将物理上分散的多个数据库单元连接起来组成的一个逻辑上统一的数据库。每个被连接起来的数据库单元称为节点。分布式数据库有一个统一的数据库管理系统来进行管理，称为分布式数据库管理系统。分布式数据库的要素如下： 数据扩展性：系统必须能够通过添加资源进行扩展，并且扩展需要平滑(尽量降低数据迁移给正常业务的影响)和自动化(统一调度配置，自动化的实现数据rebalance) 数据一致性：实现金融级ACID要求。 可用性：网络故障导致的部分分区不可用时集群的可用性，或者硬件故障导致部分节点宕机时集群的可用性保证。
• 著名的CAP理论 在理论计算机科学中，CAP定理（CAP theorem），又被称作布鲁尔定理（Brewer's theorem），它指出对于一个分布式计算系统来说，不可能同时满足以下三点： 一致性（Consistency） （等同于所有节点访问同一份最新的数据副本）可用性（Availability）（每次请求都能获取到非错的响应——但是不保证获取的数据为最新数据）分区容错性（Partition tolerance）（以实际效果而言，分区相当于对通信的时限要求。系统如果不能在时限内达成数据一致性，就意味着发生了分区的情况，必须就当前操作在C和A之间做出选择。 上面的CAP解释摘自维基百科，理解CAP理论的最简单方式是想象两个节点分处分区两侧。比如允许2个节点同时更新状态会导致数据不一致，即丧失了C性质。如果为了保证数据一致性，将分区一侧的节点设置为不可用，那么又丧失了A性质。除非两个节点可以互相通信，才能既保证C又保证A，这又会导致丧失P性质。所以根据分布式系统的CAP定理，实现ACID事务需要付出很大的成本来维护可用性，所以为了保障可用性而总结出一套弱化的事务特性：比如保证基本可用，也就是说系统能够基本运行、一直提供服务。或者弱化一致性：系统不要求一直保持强一致状态，另外就是最终一致性：系统需要在某一时刻后达到一致性要求，这是为了丰富CAP理论出现的BASE理论。
• 分布式事务 分布式事务简单举例就是：A用户在北京的银行给在海南的B转账需求，该事务的发起者、资源及资源管理器和事务协调者分别位于分布式系统的不同“节点”之上，所以只能靠分布式事务来解决。正如上文提到的分布式事务方案无法做到完全的ACID的保证，因此在实际的业务中会根据业务的特性，选择最适合的分布式事务方案。常用的分布式事务解决方案有：两阶段提交/SAGA/TCC等。 （1）2PC 目前应用比较广泛的就是两阶段提交（two-phase commit protocol），因为分布式事务需要跨越多个节点，各个参与节点都知道自己操作的成功失败，但是不知道其他节点的操作状态，这时就需要一个节点作为协调者（Coordinator）来统一掌控所有节点（参与者：Participants）的操作结果并最终指示这些节点是否要把操作结果进行真正的提交，2PC主要分Prewrite和Decision这2个阶段。大概的流程是：

图片

• （2）SAGA SAGA的核心思想就是拆分长的分布式事务为多个短的本地事务，然后由 Sagas 工作流引擎负责协调，如果整个流程正常结束，那么就算是业务成功完成，如果在这过程中实现失败，那么Sagas工作流引擎就会以相反的顺序调用补偿操作，重新进行业务回滚。 （3）TCC（try/Confirm/Cancel） TCC 其实就是采用的补偿机制，其核心思想是：针对每个操作，都要注册一个与其对应的确认和补偿（撤销）操作。它分为三个阶段： Try 阶段主要是对业务系统做检测及资源预留；Confirm 阶段主要是对业务系统做确认提交，Try阶段执行成功并开始执行 Confirm阶段时，默认 Confirm阶段是不会出错的。即：只要Try成功，Confirm一定成功。Cancel 阶段主要是在业务执行错误，需要回滚的状态下执行的业务取消，预留资源释放。
• 分布式数据库的发展 从具体数据库来看，牺牲事务的nosql比较容易跟分布式想结合，所以nosql分布式数据库较多，而关系型数据库受到分布式事务的限制，所以出现的比较晚。 另外从架构上，可以分为：“伪”分布式、基于共享存储的分布式、去中心化的分布式 （1）“伪”分布式数据库 为啥叫“伪”分布式，因为这些分布式数据库一般都是以MySQL为存储底座，通过上层的中间件来实现的，这些中间件实现了数据路由规则，将数据拆分存储到下游的MySQL分库分表集群里。比较被大家熟知的有：阿里早年开源的Cobar，后来基于Cobar思想研发并开源的Mycat。 （2）基于共享存储的分布式数据库 一般都采用存储和计算分离的架构，上层是支持MySQL协议的client，数据存储的底层是可动态扩容的分布式高性能存储，因为采用了计算和存储相分离的架构，计算层和存储层都可以动态扩缩容，并且这些分布式数据库都会对网络以及存储层的优化来保证MySQL的高可用和高性能，例如AWS的Aurora、阿里云的PolarDB等。 （3）去中心化的分布式数据库 这种分布式数据库为了平滑的扩缩容也采用了存储和计算分离的架构，说到去中心化这一点就要提到share nothing，分布式集群的每个节点都是独立节点，通过multi-paxos或者multi-raft共识算法来保证多副本的可用性，比较有代表分布式数据库有：PingCAP的TiDB和蚂蚁的OceanBase。

分布式数据库的未来

今年参加中国数据库大会（DTCC）发现分布式数据库都在讲HTAP+云原生。

（1）先说HTAP

说到HTAP（混合事务/ 分析处理，Hybrid Transactional/Analytical Processing）是gartner公司2014年在一篇论文里提到的新名词，表达的意思就是OLTP（在线事务处理）和 OLAP（在线分析处理） 的界限越来越模糊，举个例子：在一个高TPS的OLTP业务中，数据库每天的大部分工作就是将用户的消费记录不断的被写入事务引擎，但是用户其实也想实时的知道我实时的消费情况(基于用户id sum/avg group by)，这就是强需求。

一种的解决方案是数据写多份，写事务引擎时同时写流处理(Kafka/Flink/Druid等)一份，通过流处理来给用户展示SQL。另一种方案就是ETL，通过同步中间件(canal/maxwell/ticdc/dts等)来拉取事务引擎的数据变更写入到下游的OLTP/OLAP数据库来进行查询。折腾这么多流程，目的就是：避免OLAP的group by给事务引擎带来压力，从而引发抖动或者性能问题。

如果一套方案既能满足OLTP又能满足OLAP，并且实时、事务和分析资源隔离、入口统一、没有ETL赚差价、降低数据系统的复杂度，这个HTAP的需求都是各大分布式数据库厂商未来的方向。

（2）聊聊云原生

说到数据库上云(私有云k8s/公有云/DBaas)，多年前好多DBA都会问，数据库怎么能上云？数据库都是带状态的，性能是否能保证？k8s底层还多了一层网络层的消耗，等等问题。

后来随着k8s的发展，自己慢慢了解后，发现解决数据库这种有状态的可以通过（statefulset/operator），要求写入性能的可以用local PV（storageclass+PVC+PV）等方式解决问题。在这里就不展开了，后续我会有专门的文章展开来分享。

好多分布式数据库设计时就考虑到这个趋势，并且有自己的operator来上云，我想未来大部分的分布式数据库都会跑在云上的，这个也是趋势。

文章来源于晓磊聊DB ，作者Mars dai