原标题：都说“存算分离”好，分布式数据库为何还要“进一步分离”？
历史上，数据库“存算一体”和“存算分离”的变更
第一代的“存算一体”数据库是80年代的IBM大机，提供计算、数据库、存储、中间件，解决了核心交易场景对性能和可靠性的诉求，但他的缺点同样明显，贵！高昂的采购费用、封闭的硬件生态和高昂的售后维保价格，大机的垄断，即使是银行这类不差钱的企业也感到肉疼。大机有限的存储扩展能力，也限制了数据库的容量。
随着商用数据库和高端存储的发展，IOE架构出现了。IOE指以IBM小型机、Oracle数据库和EMC存储设备为代表的IT基础体系。这一架构极为“先进”和“开放”，打破了大机的垄断，在性能和可靠性上也完全满足企业业务的诉求。这一架构的出现，让数据库从“存算一体”，走向了“存算分离”。讽刺的是，随着这一架构的发展，形成了新的垄断。
随着云和互联网技术的飞速发展，数据量和用户量激增，双11购物节、12306春运抢票等突发业务对数据库业务造成了巨大的冲击。IOE架构欠缺横向扩展能力，让数据库无法满足激增的性能诉求和灵活扩容诉求。
芯片技术持续发展，Intel的Tick-Tock策略，让芯片制程和架构以每两年一次的周期进行更新，CPU的性能随之水涨船高。X86通用服务器享受到了这一红利，其性能越来越高，成本越来越低。ARM生态的持续发展，让ARM架构的处理器在服务器领域也开始崭露头角，让企业拥有了更多的选择。分布式数据库无最大节点数的限制，巨大的性能冲击可分散到海量的服务器集群并发处理。用户需求的催化和服务器硬件的发展，使得分布式数据库‘火’了起来。
分布式数据库部署灵活，极为契合云原生应用使用场景，再加上企业摆脱IOE依赖的商业考量，企业纷纷尝试使用通用服务器打造灵活易扩展的分布式数据库，数据库由“存算分离”再次转向“存算一体”。
“存算一体”架构
数据库“存算一体”不是终极解决方案
从历史上的“存算一体”和“存算分离”变更来看，客户需求和业务需求的变化才是推动架构变更的根源。
那么，当前“存算一体”的架构是否完全满足客户和业务的诉求呢？答案是否定的。
企业试水分布式数据库的初期，数据量不大，整个集群的规模有限，运行的往往不是最核心的业务，对性能和可靠性的要求相对不高。随着业务的发展，数据量持续增加，分布式数据库单库性能较差，需要拆分成500G左右的分片。为了满足性能和可靠性要求，企业往往通过堆叠服务器来解决，导致数据库集群的规模越来越大，TCO持续增加。
为了实现高可靠，分布式数据库通常采用1主多从的架构，多个从节点大部分时间都处于闲置状态，导致CPU资源利用率极低。每一台服务器就是一个数据孤岛，存储无法按需分配，数据在服务器间流动困难，导致存储利用率低且存在单点性能瓶颈。服务器故障后，无法自动切换，需投入大量人力和时间手工恢复数据，可用性变差。某运营商的核心分布式数据库，CPU平均利用率7%，存储利用率低于40%，节点故障平均4TB数据需要投入5人3小时恢复，分布式数据库“存算一体”架构资源浪费和可用性差已经成为了企业的核心之痛。
分布式数据库“存算分离”如何解决企业核心之痛
“存算分离”架构
- 提升资源利用率
“存算一体”架构需要考虑CPU、内存、存储容量/IOPS/带宽，网络IO/带宽，多达7个维度，任意一个维度的资源不满足就会导致无法满足应用诉求。而“存算分离”，按照计算和存储两个维度，将这7个维度拆分为两个领域，降低选型复杂度。分别构建计算资源池和存储资源池，提升资源利用率。扩容可实现计算和存储的按需扩容，节约投资。
- 高可用
外置存储阵列本身有非常好的可靠性设计，如RAID冗余、静默数据校验、两地三中心等可靠性保障，其可靠性等级高于服务器至少两个数量级，因此存储应该是一个“长期”的共享存储。服务器的可靠性偏弱，“存算分离”后，即使服务器故障，由于全局共享一份数据，可实现免数据复制快速恢复业务，实现分布式数据库整体的高可用。
- 高性能
采用“存算分离”架构后，由于全局共享一份数据，一些不必要的消耗可以被避免，可提升数据库整体的性能表现。例如半同步，每增加一个从节点都会导致10%的性能下降。采用“存算分离”后，不再需要半同步技术。
外置存储阵列对性能的优化更加深入，全闪存存储，尤其是全NVME的存储，可提供极致的性能体验。存储共享资源池不仅可提升资源利用率，还能利用不同应用不同时间对存储性能峰谷要求不同的特点，将所有的IO分散到所有的磁盘，实现削峰填谷，达到最佳性能。
“存算分离”将走向何方
著名开源数据库TiDB创始人黄东旭在《近十年数据库流行趋势纵览！存储计算分离、ACID 全面回归......》一文中将“存储和计算进一步分离”作为近年数据库流行趋势之首。那么‘进一步分离’到底如何做呢？且看业界大牛的做法。
- 数据库存储引擎能力下推
阿里副总裁，数据库产品事业部总裁李飞飞在《云原生分布式数据库与数据仓库系统点亮数据上云之路》一文中，提出了下一代分布式数据库系统架构，在“存算分离”的基础上继续将原本在服务器间进行同步的Redo Log下推到共享存储资源池，不再需要同步日志，减少了服务器主从同步的消耗。
亚马逊的首席技术官兼副总裁在Werner Vogels在《Amazon Aurora 是如何设计原生云关系型数据库的？》一文中介绍Aurora的“存算分离”架构。这一架构将在“存算分离”的基础上，将原来在计算节点处理的缓存层和日志层功能下推到共享存储，可提升5倍的写IOPS。
- 多主架构与多写多读
2022年1月20日，阿里对多主架构进行了灰度发布，面向多租户、游戏、电商等高并发读写的应用场景，实现从一写多读架构到多写多读架构的升级。多主架构是为了解决写性能瓶颈问题。
同阿里一样，亚马逊从Aurora MySQL 版本1开始，提供了多主集群和多写能力，在多主集群中，所有数据库实例都可以执行写操作，以提供故障时的“持续可用性”。
在2021年第四届中国金融科技产业峰会上，华为携手爱可生、海量数据发布的分布式数据库存储解决方案，提出通过数据多写使能引擎、数据共享加速引擎、数据持久保护引擎，三大引擎技术重新定义分布式数据库‘存算分离’架构。
这一架构采用华为的OceanStor Dorado全闪存作为共享存储资源池，支持分布式数据库多主架构，支持多写多读，免分库分表，提升计算密度。将page管理和日志管理下推到OceanStor Dorado全闪存，让企业存储来取代服务器做数据同步，降低服务器开销，提升数据库整体性能。
今天，各个厂商，不论是国外国内，不论是互联网企业还是传统ICT企业，关于分布式数据库“存算分离”的看法和做法，都是一致的。即在“存算分离”的基础上，进一步将原服务器运行的数据库存储引擎功能进一步下推至共享存储，释放计算节点的算力，提升单节点数据处理能力；推出多主架构，抛弃从节点，节省大量服务器投资；支持多写多读，充分发挥共享存储资源池共享一份数据的优势，免数据拷贝，降低故障切换时间。
未来，共享存储必将取代传统的分布式数据库存储引擎功能，结合容器技术，分布式数据库将完成无状态化改造。
免责声明：本网站内容主要来自原创、合作伙伴供稿和第三方自媒体作者投稿，凡在本网站出现的信息，均仅供参考。本网站将尽力确保所提供信息的准确性及可靠性，但不保证有关资料的准确性及可靠性，读者在使用前请进一步核实，并对任何自主决定的行为负责。本网站对有关资料所引致的错误、不确或遗漏，概不负任何法律责任。任何单位或个人认为本网站中的网页或链接内容可能涉嫌侵犯其知识产权或存在不实内容时，应及时向本网站提出书面权利通知或不实情况说明，并提供身份证明、权属证明及详细侵权或不实情况证明。本网站在收到上述法律文件后，将会依法尽快联系相关文章源头核实，沟通删除相关内容或断开相关链接。
