一、背景

随着各行各业电子信息化的一直加深，线上交易数据放弃了长时间高速增长的态势，对数据存储的需要越来越大，数据库管理系统（DBMS）面临越来越大的性能、空间和稳定性压力。在此过程中，得利于计算 & 存储 & 网络等硬件畛域的不断进步，业界风行的数据库管理系统逐渐从单机架构向分布式架构演变。笔者期望从梳理数据库管理系统所面临的一个又一个理论挑战及业界所提出的诸多解决方案的过程中，发现片缕灵感以指引将来的数据库开发工作。

二、从单机数据库到分布式数据库

业界起步阶段诞生的第一代交易型数据库具备以下次要特点：和程序一起运行在大型机 / 小型机为代表的高端计算机上; 利用硬件层面大量冗余设计带来的弱小可靠性来保障数据库可用性，通过间接降级硬件规格的形式来扩容数据库性能容量。即便到明天依然有很多银行外围零碎以这样的形式运行。很快，这种堆硬件模式来获取晋升的模式局限性就裸露进去了。首先，数据库可用性对硬件层面冗余的依赖贬低了大型机等存储型设施的造价，动辄单台上千万美元的价格是诸多中小客户难以承受的累赘。次之，因为性能扩容只能通过晋升硬件规格的形式实现，而硬件规格的 10% 性能容量晋升，往往须要客户付出成倍的购买老本，且整体性能极限也受限于过后的硬件倒退的天花板。因为上述所说的诸多老本起因，业界始终没有进行过尝试以 x86 服务器为代表的“便宜”硬件替换大型机来提供交易型数据库服务的致力。

三、基于共享存储的分布式数据库计划

1. 共享存储计划

首当其冲要解决的是，如何保障数据库服务的可用性。因为交易型业务往往都是企业中较为外围的往往会波及金钱相干的线上业务，因而对数据库服务的可用性有比拟高的要求。最简略地，通过把数据库架设在共享存储系统，将数据文件存储在共享存储，实现数据库实例和存储介质的解耦，从而实现数据库服务的高可用。

当数据库所在机器呈现故障时，另一台备用机器通过接管共享存储的数据文件并疾速对外持续提供数据库服务，从而保障数据库可用性。不过，传统的共享存储也是一种昂扬的硬件设施，其自身的老本 & 可用性 & 容量同样面临着硬件的限度，所以采纳共享存储的数据库计划始终难以大规模风行开来。直到起初分布式文件存储系统的日益成熟，这种数据库计划才真正地风行开来。时至今日，事实证明云盘产品能在云分布式环境提供稳固牢靠的存储服务，以 RDS 为代表的各类云数据库产品广泛通过云盘的可用性来保障数据库服务的可用性。

共享存储计划的毛病也很显著。一方面，数据放在远端的共享存储意味着数据库须要通过网络能力拜访数据，这导致比单机数据库更显著的拜访提早和性能开销。数据库计划引入共享存储，意味着额定引入了对网络 & 共享存储等更多的内部依赖，进而导致整个数据库的稳定性有所升高。

另一方面，共享存储计划须要另一台备用机器时刻期待着接管数据库服务，意味着一个数据库服务须要两台机器但却只能有一台机器在提供服务，无奈充分利用备用机器资源。因而，如何更好地将闲置的备用机器利用起来，也是一个重要的技术课题。与此同时，以后互联网时代流量特点除海量数据 / 海量吞吐外，还包含写入批改只占据申请总览的一小部分，用户申请绝大部分都是对内容的查问展现，内容查问场景对数据实时性的要求并不高。基于上述特点，既然另一台备用机器自身闲暇又能拜访到所有的数据，那是不是能够让它也同时提供一些历史版本的只读查问服务呢？是的，云盘存储计划就能通过只读节点的形式把本来灾备用的节点对外提供只读服务，从而晋升整个数据库系统的查问能力。

2. 共享存储计划的演进

然而，云盘存储计划只是绝对简略地将数据库服务架构在云盘上，只读节点无奈和读写节点同时访问共享存储的同一份数据文件，只能通过独自应用一份共享存储文件后再通过额定机制来和主节点进行同步来实现。共享存储中的数据文件自身就是有多正本的，这意味着数据库层面的多节点会带来乘法效应，节约更多的存储资源。这和进步机器资源利用率的初衷是想违反的，而且没有利用上共享存储能够被多个机器拜访到的人造劣势。那么，有没有方法让数据库实例的主节点和多个只读节点同时应用一份共享存储数据文件呢？

共享盘存储计划，通过在数据库层实现多节点间的协调同步，躲避多个节点各自对数据文件的变更抵触，从而实现一份数据存储多个节点服务的数据库架构。共享盘存储计划在利用存储产品高可用性保障数据库可用性之余，又很好地利用了共享存储的数据共享劣势提供多节点服务。

3. 可计算存储

共享盘存储计划的查问性能能够通过多个只读实例进行扩大，但写入申请只有一个读写节点能够提供服务。而读写节点的性能极限依然受限于单机硬件的性能下限，特地是网络 IO 设施的性能下限，不仅没从分布式架构中取得收益，甚至因为共享存储的额定开销反而有所下滑。那么，要怎么样能力让数据库服务的写入性能从分布式共享存储中获益呢？

可计算存储计划即是业界对这一问题给出的一份答卷。通过长时间的察看钻研，工程师们发现线上数据库服务的写入性能瓶颈通常都在网络 IO。特地是 RDS 数据库在运行期间须要不停刷写预写日志（write ahead log）/ 数据文件（data file）等多种数据到远端的分布式共享存储，占用了大量机器 IO 容量。但与此同时，RDS 数据库长久化到分布式共享存储的预写日志 / 数据文件等数据中蕴含了大量的冗余信息。比方，针对 MySQL/innodb 数据库架构下的 binlog/redolog 这两种预写日志，尽管日志格局各不相同（逻辑日志 / 物理日志），但二者都是对同一份数据批改的记录，却占用两倍 IO 流量。再比方数据库以页为单位长久化数据文件，而数据文件的页大小通常是 16KB，意味着即便只批改某一页中的一行记录，在写数据文件的时候数据库实例也会产生 16KB IO 流量，存在比拟大的写放大景象。甚至更近一步地，这一行记录的数据变更其实曾经随着之前的预写日志写到分布式共享存储，写数据文件的脏页数据齐全没有必要，是一种节约！！

单机数据库之所以采纳预写日志技术，是为了通过把数据脏页的随机写操作变成预写日志的程序写操作，从而晋升单机数据库整体性能。但预写日志技术只能推延并尽可能合并对数据文件的随机写入操作，却不能完全避免对数据文件的随机写入。单机数据库须要一直地把脏页逐渐刷写到数据文件来推动检查点，从而开释出更多的日志容量 & 管制实例故障的复原时长。而刷脏页通常属于磁盘随机写操作，特地在随机写入的业务场景下，十分影响数据库性能，是单机数据库的一大性能瓶颈点。

因而，工程师们提出了 Log is Database 的技术理念，这也是可计算存储计划的核心理念。数据库读写节点只通过必要的预写日志把数据库数据变更信息传递给分布式共享存储，而不再须要传递数据文件脏页等额定信息，读写节点机器的 IO 开销大大减少。那么，数据文件的数据变更怎么办呢？既然预写日志外面曾经有所有的数据变更信息，那分布式共享存储系统能够间接从预写日志里获取到数据变更信息，间接将其更新到相应的数据文件中。针对 MySQL/innodb 数据库架构，更是能够进一步把 binlog 日志间接省略，单单传递 redolog 日志就足以把整个数据库的数据变更传递到共享存储系统，大大减少了 RDS MySQL 数据库实例的 IO 流量，无效晋升了 MySQL 数据库的性能下限。

在此计划中，数据库读写节点只须要负责传递必要的预写日志给存储系统，不再须要解决数据文件更新保护的工作。而这部分数据保护工作因为波及大量迟缓的数据 IO 操作，往往正是整个数据库系统的性能瓶颈所在。数据库读写节点从保护数据文件的昂扬开销中脱身后，也得以领有了极高的数据写入性能。而分布式共享存储系统在解决数据保护工作时，因为本身的分布式架构劣势，人造能够通过增加新节点的形式进行程度扩大，一直晋升整个零碎的吞吐性能下限。

在海量写入的场景中，数据库通常会延缓推动检查点 & 保留较多预写日志，尽量避免频繁刷脏页导致影响数据库性能。而数据库在故障复原时又必须回放在检查点后的所有预写日志，以保障数据一致性。因而，数据库在海量写入场景故障复原中可能会因回放预写日志而耗费大量工夫，导致数据库服务较长时间无奈服务。因为存储系统的分布式架构劣势，可计算存储计划预写日志回放操作被打散到多个存储节点上并行执行，极大晋升故障复原的速度，无效缩小数据库服务的不可用工夫。

更进一步的，因为领有数据库全量历史信息，分布式存储系统可能提供历史版本数据页内容。在读取历史版本数据的时候，数据库节点只须要在数据页申请中带上历史版本信息。分布式存储系统在收到历史版本申请时，通过读取该数据页以后的数据文件和历史相干的回滚日志（undolog），而后将两者解决生产历史版本数据页后返回。由此，数据库历史数据处理工作也被下沉到存储系统，得以利用分布式存储系统的程度扩大劣势来晋升数据库的历史数据查问性能。

至此能够看到，与共享盘存储计划相比，可计算存储计划尽管写入申请只有一个读写节点能够提供服务，但该读写节点只须要负责申请解析、查问执行、事务管理、缓存治理等工作，而数据文件更新保护、数据页版本保护这部分数据库中开销极重的局部流程却领有了程度扩大的能力。这意味着可计算存储计划在保障可用性的根底上，曾经在肯定水平上解脱了传统单机数据库面临的硬件瓶颈，大大晋升了服务能力下限。

四、总结

文章篇幅所限，本文简略地介绍了基于共享存储的架构下数据库产品从单机数据库逐渐向分布式数据库眼睛的倒退历程中逐渐面对的问题和对应的解决思路。后续文章中，笔者将尝试探讨数据库的另一条倒退路线，即基于独立存储的架构下数据库产品如何从单机数据库逐渐走向分布式数据库。