本文是《云原生数据库的幕后英雄：浅谈分布式数据库的计算和存储分离》的完整版本，对技术发展的分析更详细。此外行文更轻松一点，其实也是为了弥补文章更长的阅读障碍。
引言
分布式数据库替代传统商业数据库是近年最热门和最有争议的话题。理论上没有什么数据库不能被替代，但实际上替代的代价大到亚马逊这样的巨头到了2019年才完成了去O。巧合的是，著名开源数据库TiDB创始人黄东旭在《近十年数据库流行趋势纵览！存储计算分离、ACID 全面回归......》 一文中将“存储和计算进一步分离”作为近年数据库流行趋势之首，而这正是亚马逊去O采用的主要架构。计算存储分离并没催生新的数据库，但使数据库替代的代价大大降低了，因此对它的研究有助于转变思路，解决数据库替代中的一些棘手问题。
本文将通过分析数据库计算和存储分离（简称存算分离）如何降低数据库替代的代价，供分布式云原生数据库开发和使用者参考。
计算和存储分离有多香，看看大V怎么说
随着阿里去IOE的商业成功，在普遍的认知中，在分布式数据库中使用存储成本高，扩展性差，可靠性低，甚至成了落后架构的代名词。然而2020年著名开源分布式云原生数据库TiDB创始人黄东旭在《近十年数据库流行趋势纵览！存储计算分离、ACID 全面回归......》 一文中却将“存储和计算进一步分离”作为近年数据库流行趋势之首。更有意思的是今天倡导分离的，就是包括阿里等当年提出去IOE的互联网和云计算巨头们。到底是上面的问题得到了解决，还是存算分离有什么独特的魅力，先来看看业界的巨头大V怎么说。
从Local Disk的源头发生转折
作为公有云的开创者，AWS在十多年前就推出了Hadoop托管服务EMR。但与开源HADOOP生态不同的是，EMR采用了S3存储替代HDFS作为存储层：“与本地集群要求严格的基础设施不同，EMR 可以将计算和存储分离，使您能够独立扩展每层并利用 Amazon S3 的分层存储。利用 EMR，您可以预置一个、数百个甚至数千个计算实例或容器来处理任何规模的数据……只需要按实际使用量付费。”
这反映出AWS对存算分离带来价值的认知：灵活扩展和节省成本（按量付费）。这颠覆了长期以来使用外置存储扩展性差，成本高的认知。而这些价值经受了用户的检验，在EMR的基础上，AWS逐渐形成了自己的公有云数据湖，这是一个围绕S3存储实现“数据唯一真知”的架构，数据可以低成本存储、共享和流动：
![s.jianshu.io/upload_images/25580475-58933d1acbe23ae0.PNG?imageMogr2/auto-orient/strip%7CimageView2/2/w/1240)
有行业巨头带路，大家纷纷效仿，比如阿里云的数据湖和AWS很像：
从去IOE回到计算和存储解耦
存算分离之风此强劲，以至于去IOE的布道者阿里也转向了存算分离。阿里副总裁，数据库产品事业部总裁李飞飞在《云原生分布式数据库与数据仓库系统点亮数据上云之路》中说：“传统的冯诺依曼架构下计算和存储是紧密耦合的，可将多个服务器通过分布式协议和处理的方式连成一个系统，但是服务器和服务器之间、节点和节点之间，分布式事务的协调、分布式查询的优化，尤其要保证强一致性、强ACID的特性保证的时候，具有非常多的挑战。……云原生的架构，本质上底下是分布式共享存储，上面是分布式共享计算池，中间来做计算存储解耦，这样可以非常好地提供弹性高可用的能力，做到分布式技术集中式部署，对应用透明。避免传统架构当中的很多挑战，比如分布式事务处理、分布式数据如何去做partition和sharding。”
按阿里张瑞回忆，在“倒戈”前就使用外置存储是不是一种倒退进行过激烈讨论。但最后发现如果不解耦就无法支撑双11这样的业务高峰弹性扩展要求和性能冲击，这正是李飞飞提到的“紧密耦合”的挑战。同时阿里的“倒戈”也是受了AWS的影响。与阿里不同，亚马逊2019年才完成全面去O，曾和自称从亚马逊出来的人聊过，据说这主要是因为亚马逊是在少改动应用的情况下进行的去O，因此对数据库的要求上，就更接近商用数据库（下文会详细拆解Aurora的设计目标和架构）。最终AWS采用了存算分离的架构并把大量能力构建在存储层，“力从地起”实现接近商业数据库的能力目标。
目前阿里、腾讯、华为云的云原生数据库都参考了这个架构，只是相似度不太一样。
从自研存储到通用存储
上面几家是上（数据库）下（存储）内（自有业务）外（公有云）通吃的，Facebook这种自己玩的互联网厂商完全从自己的业务需要出发研发了一套温数据存储，以存算分离的架构来支撑亿的用户量产生的大数据。对于为什么要做存算分离，FaceBook有独到的观点，后面会详细分析。除了这些能自研存储的，Snowflake走了一条采用通用对象存储构建公有云数据仓库服务的道路，并实现了数据仓库的计算无状态化：
Snowflake的架构受到了TiDB创始人黄东旭的推崇。在他存储和计算分离作为首要趋势的分析中便是以Snowflake和AWS Aurora为样本的。
云原生中无处不在的存算分离
云原生一直在努力实现无状态化（关于云原生为什么需要存算分离在下面“云原生：不可变基础设施带来可靠性提升和弹性扩展能力”小节分析），而实现的手段就是把数据层剥离出去！只不过在应用层，数据可以剥离给缓存、数据库、文件存储和消息队列，到数据库、消息队列也要实现云原生时就只能自己做存算分离了，Snowflake的无状态架构便是一例。而最近大火的消息队列Apache Pulsar 给自己的定义是这样的：
Apache 软件基金会顶级项目，下一代云原生分布式消息流平台，集消息、存储、轻量化函数式计算为一体，采用计算与存储分离架构设计，支持多租户、持久化存储、多机房跨区域数据复制，具有强一致性、高吞吐、低延时及高可扩展性等流数据存储特性。
而对于Pulsar的云原生特性则是这么描述的：
可见实现云原生存算分离已是无处不在。
何为计算、存储和分离
不过不要以为大佬们讲的是一个事，由于架构，商业目的不同，做法差别会很大。对数据库使用者，不需要关心这些细节（可跳过此章）只需要关注最终方案的效果，但对云和数据库规划运维者则需要看清这其中的演变（没错，是不断变化的）的逻辑才能更好地进行选型与规划。
计算：提供计算能力的不可变基础设施
存算分离中计算的变化比较小，也更容易理解：不管是开始的虚拟机还是现在最常用的容器，计算部分都是提供算力的，其最基本的资源是CPU和内存。一些“计算”还会用Local Disk作为缓存，但并不包括持久化数据。这也使“计算”不断接近云原生中对不可变基础设施的要求。
存储：能力不断增强的数据持久化资源池
相对计算，存储的能力，形态则变化较大。但不管是对象存储，HDFS存储，KV存储，文件存储，还是像AWS那样提供了部分数据库存储引擎功能的“计算存储”，不管是自研还是购买或使用开源系统，是云服务还是线下存储，存算分离中的存储始终承担着数据持久化的工作。这一点是理解存算分离的关键，也是存算分离的主要价值之一。
不过正像“计算存储”抢了计算的活儿一样，如果哪天出了个以共享缓存为主要功能的存算分离我也不意外，因为已经有这样的苗头，不过我认为数据持久化将一直是“存”的主要工作。
分离：下刀的位置因时而变
分离容易理解，但怎么切是有讲究的，它反映了需求，能力，以及商业考量。
如果想让存储多做点事，可以切得多一点，像AWS Aurora把日志引擎都切给存储了；
如果想通用一些，也可以像阿里PolarDB那样存储仍然做数据持久化用，以至于底层换个存储也能用；
以上反映了技术能力和需求的平衡。
对公有云，接口一般不会开放，怎么切肉都烂在锅里；
对于单纯的数据库厂商，会倾向基于通用存储重新开发，Snowflake就基于对象存储来开发；
存储厂商则倾向以通用接口来做“分离”，并会在此基础上进行增强，华为，浪潮的大数据存储，腾讯的HDFS存储都在存储上实现了HDFS接口协议，方便用户迁移到分离架构上来，同时相比一体化方案在成本，可靠性等方面又都有增强；
以上反映的商业考量。
甚至除了真切外还可以“假”切。Hadoop有单独的存储HDFS，实现了“计算可移动”，这已经在逻辑架构上实现存算分离了，虽然当时技术上还不具备完全分离的条件。但为后来的物理分离提供了便利。目前仍然有一些“分离”是逻辑上的，是否做物理上的分离，规划者可以根据自己面临的问题与技术条件来选择。
技术发展使存算分离成为可能
HADOOP只进行逻辑分离反映和技术与需求间的妥协，而存算分离能再次流行是因为当时的技术障碍传输性能与存储能力问题已得到解决。
技术拐点：分离正当时
FaceBook在其阐述温存储大数据研发的原因中提出了“技术拐点论”非常准确的说明了当下为什么可以实现存算分离的技术原因：传输协议和带宽能力已不再是IO瓶颈，其中很多技术除了用于数据库也是云计算存储部署甚至是大型数据中心构建的关键技术，值得研究，但限于篇幅，这里列出厂商的技术应用情况和部分文章链接，后续有必要可能会对部分技术再做深入分析：
高速以太网：随着数据中心网络从当年的千兆迈入10GE,25GE，甚至100GE时代，吞吐量大幅提升而成本和部署灵活性相比FC和IB有大幅度改善。
-
无阻塞转发网络：比如FaceBook采用了CLOS网络拓扑，实现了分解式的网络网络不会成为性能瓶颈，同时提供了灵活的组网能力：
Facebook的分解式网络架构Fabric ROCE和NOF（NVMe over RoCE）：这个集合了RDMA，NvME，以太网的缝合怪从协议层匹配了SSD介质的性能需求。阿里PolarDB和AWS最新的IO2 Express使用了ROCE。
无损网络：保证网络稳定性，使以太网可以用于高速关键业务
而相对于传输能力和协议的发展，近年介质能力和协议的提升不大，此消彼长，技术拐点已经来临。
存储能力提升
这是比较容易忽视的一点，AWS最近不小心说漏了嘴：去年底的re:Invent 2020上AWS宣称推出首个云上SAN存储（到现在还是预览版），这个“首个”暴露了云存储直到现在仍没有能力在技术上（其实价格上也不行）与企业存储竞争。相对传统厂商，云厂商的强项是对象存储，巧的是大数据和分析型数据库也是最先基于对象存储搞存算分离的。
不过经过近十年的投入，还是有了些积累，2012年AWS有了第一代高性能块存储IO1，2014年有了Aurora。阿里去IOE和自研存储项目盘古前后脚开始的，而分离架构的PolarDB则是在盘古2.0（2018年正式发布）还没正式发布时就在2017年用上了。虽然云上存储能力仍不及企业存储，但存算分离已不再难以实现。
新通用存储+数据库形成开放架构
这个“新”指通用存储具备的新特性，既能提供比本地盘更好的能力，也有别于传统存储。这使开源或Snowflake这样的数据库厂商更容易从分离架构中获得优势，而无需自己研发存储。对于存算分离，比较关键的特性包括：
低成本：这主要用于大数据数据湖类海量数据应用，对交易类数据库，因为规模相对小并且关注点不同，则不一定是主要关注点；
高性能：交易类的业务性能要求高，全闪存存储AFA是比较合适的选择，甚至AWS都收购了一家全闪存厂商E8来加强自身存储能力；
-
扩展性：有趣的是现在的企业存储也分布式了，这使它的"返场"不会造成性能和扩展性问题
华为企业存储也具备分布式架构 增强功能：比如专门用于大数据的HDFS存储，用于增强Mysql等开源数据库能力的可计算存储等
需求决定是否要做存算分离
技术决定可行性，需求决定必要性。分布式云原生数据库采用存算分离架构的需求来自两方面：云和提升数据库能力，也就是降低数据库替换中的代价。了解存算分离能解决哪些问题及解决方法，对是否需要以存算分离以及如何规划构建存算分离方案意义重大。
云的必然选择
新一代数据库，尤其是分布式数据库，普遍采用云计算部署方式，甚至一些新生代数据库就是为云而设计的（所以叫云原生数据库？）。即使不考虑云的因素，替代oracle时造成的集群规模暴涨也需要考虑资源分配，弹性扩展，故障切换自动化等需求。对于分布式数据库来说采用存算分离可以归结为资源使用和云原生的需要。
云原生：不可变基础设施带来可靠性提升和弹性扩展能力
不可变基础设施指基础设施生成后就不再做变更，这是云原生的主要特征之一。我们来看看AWS认为当计算可以在任意服务器上生灭时，会发生什么。
首先是计算发生故障时，由于不需要重新在新服务器上恢复数据，因此实例可以快速恢复。Aurora采用了共享存储架构的一写多读架构，只需要在计算实例间同步少量缓存信息，因此读实例可以快速恢复成主实例，理论上可以接近ORACLE RAC的切换速度。
其实即使实例间没有使用同一份共享存储，在存算分离后，也不需要全量恢复数据了，这样数据库恢复到工作状态的时间就大幅度缩短了。京东就采用了这种方式，避免了数据恢复中日志恢复慢和高负载下可能追不上日志的问题。
另外存算分离后计算实例可以摆脱物理服务器的束缚任意迁移而不需要进行数据同步，这使得弹性扩展变得极为容易。再看前面阿里李飞飞的观点：“……这样可以非常好地提供弹性高可用的能力”就顺利成章了。对于这方面的详情和趣事，可以看一下 《“双11”十年记 阿里数据库演绎变迁三部曲》中“存储计算分离的技术突破”一节。
看到这的朋友可能会有个疑问：如果数据都集中到存储上了，如果存储出问题了怎么办？这个问题我们后面再分析。
把规划变简单，提升资源使用效率
我们平常接触的世界是三维的。相对论把世界变成了4维，但也只解释了引力，另外三个要靠量子力学。而要统一相对论和量子力学，目前最有希望的理论弦理论认为世界是11维的！
对于数据库这类复杂的应用如果使用服务器本地盘，在资源规划时要考虑CPU、内存、存储容量/IOPS/带宽，网络IO/带宽，差不多7个维度。云计算解决这个问题的思路与物理学一样，一靠近似，就是忽略到一些维度，比如不管需求有多少，把服务器的配置统一成两三种。但这样一来，资源利用率不可能高。二是像拆分出相对论和量子力学两个看似矛盾的理论一样，把计算和存储解耦，这便是李飞飞“云原生的架构，本质上底下是分布式共享存储，上面是分布式共享计算池，中间来做计算存储解耦”的目的。
以较小代价提升数据库整体能力的需要
李飞飞在《云原生分布式数据库与数据仓库系统点亮数据上云之路》提到：“一旦做了分布式架构，数据只能按照一个逻辑进行Sharding和Partition，业务逻辑和分库逻辑不是完美一致，一定会产生跨库事务和跨sharding处理，每当ACID要求较高的时候，分布式架构会带来较高的系统性能挑战，例如在高隔离级别下当distributed commit占比超过整个事务的5%或者更高以上的话，TPS会有明显的损耗。”
所以阿里和AWS的策略都是将数据库“变大”（Scale Up）也就是李飞飞说的100T的一个库。当然实现这个目标，也不仅是容量扩展，阿里和AWS都利用存储的能力实现了性能的增强。同时类RAC架构能更好的扩展计算性能。
其实这只是架构导致的问题之一。如果对比一下企业数据库，HADOOP，和Mysql的主从同步方案就会发现一个问题：Hadoop因为有独立的HDFS存储层，它的可靠性是构建在HDFS存储层之上，而不是像Mysql构建在主从同步或MGR之上。相对来说，前者的效率要更高，可靠性更好。
业界大佬们采用存算分离，而不是一味投入到对数据库架构和功能的优化上，从而“让数据库替换的代价变小”。纵观业界的数据库存算分离方案，除了之前提到的云原生之外，一般会从这几方面入手：
可靠性
存储本身就有非常好的本地和灾备可靠性能力，反倒是服务器的可靠性偏弱。因此在AWS看来计算是“损坏后被替换”的，而存储却是“长期”的。存储可以实现Local Disk很多无法实现或难以实现的可靠性功能：
-
本地可靠性冗余：
如前文所述，基于本地盘实现冗余，如Mysql半同步在业务压力大时会变异步有丢数据风险；有些则对网络条件要求高，性能损耗大；有些在服务器上实现困难，如对NvME盘的RAID，或者效率上不如在存储上实现。还有像Aurora这样的类RAC方案，则必须要有存储配合。
不过必须指出同样由于像Mysql这样的数据库中缺少专业的本地可靠性方案，存储的可靠性方案中的一部分功能，比如Aurora多AZ高可用方案也需要数据库的配合来发挥价值。
还是这张图Aurora的本地和跨AZ高可用是统一的，并通过存储实现数据可靠性部分，用存算分离实现计算可生灭，并集成在整体方案中。
数据校验：还记得腾讯的磁盘静默吗？这个功能在存储上是标配，但在服务器系统层则很少考虑，如果数据库想做，那得自己开发这部分功能。
容灾：以Mysql为例，大事务或批处理业务都可能导致半同步退化。相对来说存储层实现容灾对数据库压力的敏感性要低。比如AWS Aurora就是用存储实现一个可用区+另一可用区一个副本故障时仍能提供服务的能力。
备份：数据库备份恢复要依靠全量副本+增量日志，恢复时间会相当长。存储一般都有快照功能，可以用来做备份。AWS和阿里就是把建立在存储上的云备份功能直接用在了数据库上，也就是上面图中的S3。
以上这些是存储多年积累的基本能力，现在又被重新应用到分布式数据库中了。而在可计算存储基础上，可以实现更多的能力，比如对表的闪回。
性能
在传统的认知中，性能是使用共享存储的巨大阻碍。但近年云厂商的实践和宣传中又在不断打破这种认知。这主要是因为通过架构的改变，以及存储针对数据库的优化，可以解决Local Disk方式难以解决的一些性能问题，从而达到性能的提升，这些优化包括：
解决可靠性问题时，一些性能消耗可以避免或降低，如增强半同步对性能的影响就很大，增加一个节点会影响约10%的性能。通过存储解决数据可靠性则没有多大影响，但如果仍然使用传统的HA方式，故障切换时间会比较长，因此类似RAC的架构又成了首选。
存储对性能的优化更深入，如对SSD介质的优化催生了全闪存存储。这一类型存储的出现甚至晚于分布式存储。2019年AWS收购了一家全闪存存储公司，转年就推出了自己的云上“SAN”存储
资源池部署的均衡与削峰填谷作用，由于存储可以使用大量磁盘分散IO，同时由于各个应用的负载不同，峰值时间不同，因此可以实现削峰填谷，在平衡成本的情况下达到更好的性能。
新技术的应用，如对SCM，FPGA的应用。存储上使用这类技术会尽量实现对应用透明，也就是应用不需要适配改造就能享受这些新技术的好处。
IO优化：AWS的日志即数据库是非常深度的IO优化，其实还有其它方案，比如关闭双写（Double Write）。
QoS：实现对存储 IO的隔离在操作系统层面比较困难，而存储QoS则是标配。
存算分离回归，既是轮回，也是新生
这里算是对本文做个总结。数据库的存算分离在我的IT从业生涯中已经发生两次了。第一次产生的曾经打破大机垄断，后来却成为垄断的IOE架构，第二次则是当下的云原生数据库。未来也可能再次出现这种架构的交替。我们是否需要存算分离，当下的存算分离能给我们带来什么新价值呢？
架构回归是需求博弈的产物
回顾一下，存算分离的基本技术架构虽然被套上了云原生，ServerLess等新名词，但和20年前没有本质变化。在没有技术障碍时，如何选择，本质上取决于需求。
当互联网云计算公司要实现技术自主时，这个需求压倒了一切，结构简单的一体化架构就成为了必然；
当分布式数据库的实践逐步深入时，效率问题逐渐突显，存算分离的必要性就显现出来了；
当系统规模较小时，简单往往是最好的。同时存算分离也需要在一定规模后才有明显的成本、可靠性和运维优势。因此具备一定规模的系统，尤其是公有云和私有云，采用分离架构是必然。
对于独立数据库厂商来说，选择哪种架构取决于还是否能带来商业的成功，这是SnowFlake选择存算分离的逻辑，也是一些厂商选择更简单的一体化构架的逻辑。
而对于大多数数据库用户来说，最终的结果大于技术自主这类战略上的意义，无需关注底层架构，只要关注数据库整体的性能、成本、可靠性是否最优。
存储归来变智能
存储传统上只被用来保存数据，而在近年来，存储逐渐“抢”了一些数据处理的工作“分担”计算层的工作。而这个能力对于数据库减少采用分离架构后的IO量有明显的效果，因此AWS搞了日志即数据库后，大家纷纷效仿。可计算存储的概念浮出水面，未来可能会是数据库存储的主流。
从封闭重新走向通用
上一波存算分离，催生了小型机+存储的开放架构，没错，当年这就是开放架构！如今公有云的一体化，全栈模式重新表现出了封闭性。存算分离会吸引更多厂家投入，未来很可能出现又一个开放架构时代。