最近把PolarDB的存算分离架构和传统自建MySQL架构拉到同一个擂台上完整跑了一轮Benchmark。这轮对比测试前前后后折腾了两周中间踩了不少坑也修正过好几轮测试方案最后拿到一批比较干净的数据。这里把测试思路、环境设计、实测结果以及数据分析全部整理出来给正在纠结“云原生数据库到底行不行”“存算分离是不是营销概念”的朋友一个参考。先交代一下这份内容适合谁。如果你正面临数据库架构选型或者你在给现有业务评估是否要迁移到PolarDB这类云原生数据库又或者你只是想搞明白传统主从架构和存算分离架构的性能差异到底来自哪里这篇文章应该都能给你提供一些可落地的判断依据。测完这一轮我对“存算分离是纸面优势还是实际价值”这个问题有了非常具体的答案下面逐步拆开说。1. 先把两个架构摆清楚存算分离与传统架构到底在比什么1.1 传统架构的IO路径与性能瓶颈我口中的“传统架构”指的是最经典的自建MySQL部署方式一台物理机或者云主机数据落在本地NVMe SSD或者网络云盘上主库负责读写再用异步复制或者半同步复制搭一个或多个备库。这套架构是最成熟的绝大多数互联网公司跑了很多年踩坑经验也最丰富。传统架构的写路径是这样的应用发来一条UPDATE语句MySQL内核先更新Buffer Pool里的数据页然后写redo log写binlog事务提交时还要把redo log fsync到磁盘。如果开启了doublewrite还要处理doublewrite buffer。数据页本身则由后台线程在适当时机刷到磁盘。这个路径上任何一个环节出问题都会直接拉高写入延迟。更关键的是在主从架构下主库写完binlog后要把binlog通过网络传输给备库备库再通过SQL线程回放。这个复制链路引入了额外的延迟窗口半同步复制虽然能缓解数据丢失问题但会进一步延长主库提交的等待时间。备库回放慢了读写分离场景下就会出现“主库写入马上查不到”的数据不一致问题这也是传统架构最让人头疼的地方之一。1.2 存算分离架构的核心差异PolarDB的存算分离架构把计算和存储彻底拆开了。计算节点只负责SQL解析、执行计划生成、事务处理和Buffer Pool缓存不再持久化数据文件。数据全部存放在底层的分布式共享存储PolarStore上计算节点通过网络访问。这里最核心的变化在于写路径。PolarDB的计算节点不再需要把数据页刷到本地磁盘而是把redo日志通过专用网络发送到存储节点由存储节点侧完成日志回放和数据页合并。也就是说计算节点只需要保证日志成功写入PolarStore并返回确认事务就能提交。它省掉了一大批本地磁盘操作写放大被大幅压缩性能上限自然不一样。计算和存储之间用的是RDMA网络不是普通的TCP/IP。RDMA的优势是低延迟、低CPU开销数据在内核里可以直接绕过性能表现跟本地NVMe设备的差距被缩得非常小。再加上ParallelRaft协议在存储层做多副本同步数据的一致性和持久性由存储层保证计算节点之间则通过共享存储天然实现数据可见。1.3 为什么要把两者放在一起对比传统架构的性能瓶颈在于“每一份数据都要在本地落盘、再在网络上复制”PolarDB这类存算分离架构的性能逻辑则是“日志只写一次数据由存储层兜底”。这两者优化路径完全不同如果不做一轮控制变量的实测单纯看云厂商提供的规格参数很难直观理解性能差异的真实来源。做对比测试时我给自己定了一个原则除了“架构”这个变量本身其他条件尽量保持一致。CPU规格、内存大小、数据量、并发模型、参数配置能对齐的全部对齐。不然测出来的差距到底是架构差异还是配置差异根本说不清。2. Benchmark方案设计测什么、怎么测、用什么工具2.1 工具选型为什么用SysBench这次测试我选的是SysBench 1.0.20没有选TPC-C类工具。原因很简单SysBench是OLTP场景压测的事实标准插件化设计能精准控制并发数、测试时长、事务模型结果容易重复验证。TPC-C这种工具更贴近真实业务形态包含商品、订单、库存等多表事务但配置成本实在太高需要建库、导入数据、调整事务权重一轮跑下来光是排查环境问题就要花很多时间。第一轮架构对比我更关心的是数据库引擎在不同读写模型下的基础能力SysBench的oltp_read_only、oltp_read_write、oltp_write_only、oltp_point_select这几个脚本已经足够覆盖。SysBench的常用命令大概是这样的sysbench --db-drivermysql \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-userbench \ --mysql-passwordbench123 \ --mysql-dbsbtest \ --tables10 \ --table_size5000000 \ --threads128 \ --time600 \ --report-interval10 \ oltp_read_write run参数含义也很直白10张表每张500万行总共约5000万行数据量大概是10GB左右。这个数据量能把Buffer Pool跑热测试结果更能反映CPU和IO路径的真实能力而不是冷数据读盘的极端场景。2.2 测试环境与规格说明测试环境我准备了三组尽量把差异性控制在架构本身架构计算规格存储配置部署方式传统架构A8核64GBESSD云盘PL1云主机单机部署传统架构B8核64GB本地NVMe SSD x2物理机单机部署PolarDB8核64GB x21主1只读PolarStore共享存储存储与计算分离部署传统架构A模拟的是大部分企业用云主机的场景存储走网络云盘IOPS有上限传统架构B模拟的是追求极致性能的自建机房场景用本地NVMe性能释放最彻底。PolarDB则是标准的存算分离部署计算节点规格对齐前两组。软件版本方面传统架构用的是MySQL 8.0.34PolarDB使用兼容MySQL 8.0的版本。关键参数统一调整innodb_buffer_pool_size设置为48GBinnodb_flush_log_at_trx_commit1sync_binlog1max_connections2000。这样能保证事务持久性的语义一致不会出现“为了让PolarDB更好看而故意调低传统架构参数”这种不公平对比。测试机和数据库服务器在同一内网用千兆以上网络连接PolarDB计算节点与PolarStore之间的RDMA网络由产品侧自动配置。2.3 测试场景与指标口径场景分为四组只读、写入、读写混合、高并发P99观测。每个场景先预热10分钟再正式压测10分钟取3次结果的平均值。预热非常关键目的是让Buffer Pool达到稳定状态避免冷数据导致测试结果失真。指标重点看四个QPS、TPS、平均延迟、P99延迟。QPS代表吞吐能力P99延迟代表系统在压力下的稳定性和毛刺情况。很多测试只给平均延迟这个指标其实掩盖了长尾问题——数据库在高负载下抖动非常常见P99能更真实地反映用户体验。3. 实测数据全景三组架构的对比结果3.1 只读场景核心查询能力的对比先看128并发下oltp_read_only的测试数据架构QPS平均延迟(ms)P99延迟(ms)传统架构A云盘46,8215.519.87传统架构B本地NVMe61,3474.197.26PolarDB主节点69,5283.716.05PolarDB 1主1只读118,4362.175.33只读场景下PolarDB主节点比本地NVMe部署的传统架构高了约13%只读节点加进来后整体吞吐接近翻倍。原因不难理解只读查询的主要开销是CPU执行计划和Buffer Pool访问PolarDB计算节点的本地缓存命中率和CPU调度与物理机相当再加上架构优化单节点吞吐确实更占优。传统架构A的数据也比较意外云盘在128并发只读时并没有被IOPS限制拖垮因为数据全部在内存中命中磁盘并没有成为瓶颈。这也说明一个道理如果Buffer Pool能装下全部热数据网络存储和本地存储的差异会被内存掩盖这时候性能差距更多来自引擎本身和网络协议栈的优化。3.2 写入场景IO路径差异的放大镜高并发写入是最能体现架构差异的场景。我用oltp_write_only和oltp_read_write分别做了测试128并发结果如下架构写入QPS读写混合QPS传统架构A云盘12,64217,865传统架构B本地NVMe19,83125,394PolarDB主节点28,97533,628写入场景的差距比只读大得多。PolarDB主节点比本地NVMe的传统架构高出约46%比云盘部署高出一倍多。这才是存算分离架构真正的价值所在——它不是靠单机硬件堆出来的性能而是通过精简IO路径实现的整体提升。为什么写入会有这么大差距传统架构写一次事务要经历redo log fsync、binlog fsync、doublewrite刷盘、数据页异步刷盘等多个环节任何一个环节的延迟都叠加在事务提交路径上。PolarDB的计算节点只需要把redo日志通过RDMA发送到PolarStore存储节点收到日志并完成多数派确认后即可返回成功本地不再有fsync等待。这条路径变短之后写延迟的基数大幅下降吞吐自然就上去了。3.3 高并发下的P99延迟表现并发从128提升到256和512时三组架构的表现开始明显分化。架构256并发 P99(ms)512并发 P99(ms)传统架构A云盘18.6243.75传统架构B本地NVMe14.1831.24PolarDB主节点10.4518.76最值得关注的是PolarDB在512并发下P99还在20毫秒以内而传统架构A已经飙升到43毫秒。这里面有一个很重要的细节传统架构在高并发下线程调度、锁竞争、IO队列深度会同时恶化任何一个环节出现瓶颈都会引发明显的长尾延迟。PolarDB因为写路径短、IO等待少整体越到高并发越稳。不过这里要说清楚P99表现也跟测试客户端的规格有关。我们当时用的是16核32GB的压测机512并发时客户端本身的CPU已经接近70%了。如果压测机性能不足会直接把客户端瓶颈算进数据库延迟里导致数据失真。这一点后面详细讲。3.4 横向扩展后的整体吞吐对比把只读场景扩展到2个节点对比架构1节点QPS2节点QPS扩展比传统架构B本地NVMe主从61,34798,2261.60PolarDB1主1只读69,528118,4361.70传统架构从1节点扩展到2节点用的是主从复制备库要先把主库的binlog拉过来再回放。只读流量打到备库上时备库需要消耗CPU做回放这会和查询请求互相抢占资源扩展比很难做到线性。PolarDB的只读节点共享同一份存储没有本地数据拷贝过程也不需要回放binlog它只需要在共享存储之上提供缓存和计算能力所以扩展比更高节点加得越多优势越明显。这也解释了为什么很多互联网公司在业务高峰期会临时给PolarDB加只读节点用完再缩掉——因为新节点秒级拉起不需要等待数据拷贝完成。4. 性能差距背后的原理为什么存算分离能打4.1 写路径重构一条日志走天下的含金量数据库写入的本质是“把变更记录下来保证不丢”。传统架构的做法是把变更同时记录到redo log和binlog还要把数据页本身刷到磁盘三重保障分别落在不同的文件上每个文件都有各自的fsync等待。PolarDB的做法完全不同。计算节点把变更打包成redo日志通过RDMA网络发送到PolarStore存储节点存储节点在多个副本之间确认持久化之后返回成功。数据页的合并、落盘、多副本同步全部在存储层完成计算节点对这些过程无感。用一个生活化类比传统架构是每个人写完文件都要亲手跑到档案室把原件放进A柜、复印件放进B柜、索引卡放进C柜每一步都要等管理员盖章确认PolarDB是前台统一收件收完直接放进统一的智能档案柜档案柜自己负责多副本备份和归档整理前台收到“已收妥”的确认就能去接待下一个客户了。前台计算节点的负担自然小得多。4.2 存储层多副本与一致性协议PolarStore的多副本一致性靠ParallelRaft协议来保证。和传统主从复制的异步/半同步模式相比ParallelRaft的设计目标是在保证多数派一致的前提下把日志同步的并行度做高同时降低同步延迟。传统半同步复制为什么慢因为主库要等备库返回ack才提交备库的回放线程是单线程的或者多数情况下是串行处理一个个事务主库等待网络往返加上备库落盘的时间延迟天然就上去了。PolarStore这边数据日志被拆分成多个分片并行处理单条路径的写入不阻塞其他路径整体链路更短。此外因为存储层已经保证了多副本一致计算节点之间共享数据主节点故障时备用计算节点直接挂载同一份存储完成接管不需要再等数据同步到新节点。这也是存算分离架构在故障切换场景下比传统架构快一个数量级的原因。4.3 缓存与共享存储的组合读放大被消除很多第一次接触存算分离的人会问数据都不在本地了读操作不是应该更慢吗实测数据给出的答案是并不会。原因在于计算节点保留了完整的Buffer Pool缓存读操作先走本地内存命中率足够高的情况下大多数读请求根本不会触达存储层。真正会发生存储访问的是缓存未命中的读请求。这时候PolarDB需要从PolarStore通过网络读取数据页。RDMA网络的单次往返延迟已经非常低加上数据页的读取是精细化的按需读取而不是把整个文件拉过来实际感知到的延迟并不高。传统主从架构反而是读放大很严重的场景——备库收到查询请求如果Buffer Pool没有命中就要回本地磁盘读页主库的Buffer Pool明明有这份数据却没法直接“借”给备库。存算分离天然解决了这个问题所有计算节点共享存储缓存未命中时都向PolarStore请求数据页而PolarStore的热点数据本身也有缓存加速机制整体的读命中效率更高。5. 测试过程中踩过的坑与排查实录5.1 压测工具本身成了瓶颈第一次跑512并发的时候数据出来了但怎么看怎么不对劲P99飙到50毫秒以上QPS却几乎没涨。我第一反应是数据库不行后来仔细排查发现压测机自己先扛不住了。SysBench是单进程多线程模型512并发时线程切换和锁开销非常严重加上压测机同时还在采集监控数据CPU直接打满。后来我把压测机换成更高规格的机型并做了两步优化一是给SysBench进程绑定CPU核心减少调度抖动二是开启--report-interval10每隔10秒输出一次中间指标方便观察时间维度上的变化趋势。这里给大家一个建议压测之前先确认压测机CPU使用率不超过50%网络带宽也没有打满。如果压测端先到瓶颈测出来的延迟数据就是错的这个错误还会被误判为数据库性能问题。5.2 网络类型不一致导致结果失真PolarDB第一轮只读测试的数据很不好看主节点QPS只有4万多比本地NVMe还低这与我的预期完全不符。后来检查网络发现压测客户端和PolarDB计算节点虽然在同账号同VPC下但安全组策略把RDMA链路给挡了一部分数据走的不是预期的低延迟路径。这个经历告诉我们测试存算分离架构前一定要先确认网络链路。最简单的验证方法是用ping测试计算节点与存储节点之间的延迟如果是跨可用区或者有防火墙策略延迟会飙到几毫秒甚至更高这会让存算分离架构最核心的低延迟优势荡然无存。另外一个容易忽略的点是不要把PolarDB的“本地缓存”理解成“本地磁盘”。计算节点重启后Buffer Pool是空的如果直接跑测试读请求全部穿透到存储层数据看起来会非常难看。测之前一定要做预热或者依赖SysBench执行过程中的缓存自热前几分钟的数据丢弃不要计入统计。5.3 参数调优差异造成的“不公正对比”这个问题在传统架构上尤其严重。MySQL默认配置下innodb_buffer_pool_size只有128MBinnodb_flush_log_at_trx_commit1了很多场景没开binlog也没开。用默认参数跑出来的数据和经过完整生产参数调优的数据库比性能差距会达到好几倍。为了保证对比公平我做了一张参数对齐表把三组环境的参数逐项确认过Buffer Pool大小、日志刷盘策略、binlog开关、并发线程上限、IO相关的innodb_io_capacity、innodb_flush_method全部保持一致。参数对齐这个环节没有捷径可走每一项都要确认到位不然结果没法解释。5.4 常见问题速查表问题现象可能原因排查与解决高并发下QPS不涨、P99飙升压测客户端CPU打满提高压测机规格、绑定CPU、减少监控干扰PolarDB只读性能远低于预期网络未走RDMA链路或未预热检查网络延迟、执行预热脚本后再测试传统架构表现极端差MySQL参数未调优对照生产参数逐项调整后再对比多次测试结果波动大冷热数据不一致、后台任务干扰每轮测试前重启实例丢弃前几分钟数据多轮取平均写入性能数据差异巨大事务持久性配置不一致确认flush_log_at_trx_commit、sync_binlog参数一致只读节点加入后吞吐不升反降只读节点规格过小或网络带宽受限确认只读节点CPU/内存规格检查网络带宽6. 存算分离的影响范围性能对比之外它改变了什么6.1 对DBA日常运维的改变存算分离架构带来的改变远不只在Benchmark数据上。对DBA来说日常运维的工作重心会发生明显迁移。传统架构下DBA最大的日常焦虑是主从复制延迟。备库回放慢、网络抖一下、大事务上来了延迟监控就开始告警读写分离业务随之出现主从不一致。PolarDB因为只读节点直接挂在共享存储上没有binlog回放这个环节复制延迟的概念被大幅弱化。DBA不需要再花大量时间处理复制中断和延迟问题。备份恢复的体验也完全不同。传统架构做物理备份动辄几个小时的备份窗口恢复时要重新搭实例、导数据PolarDB的备份是在存储层做快照秒级完成恢复时直接基于快照创建新实例分钟级就能拉起一个完整的环境。对于需要经常做数据恢复演练的团队这个效率提升非常可观。6.2 对应用架构与成本规划的影响存算分离对应用架构的影响最重要的是“读写分离的灵活性”。传统架构下要加一个只读副本先要申请机器、搭主从、等数据同步完成整个过程几十分钟到几小时不等。PolarDB加只读节点是分钟级别的操作用完还能释放这让“弹性伸缩”真正在数据库层面落地了。成本方面要算两本账。第一本是存储账传统主从架构下主库和备库各存一份完整数据两倍的存储成本加上备份又是一份PolarDB的存储是共享的不管加多少个只读节点底层只有一份PolarStore数据存储成本明显下降。第二本是计算账PolarDB的计算节点按规格付费如果业务对CPU要求不高最小规格起步后续按需升配比传统架构更灵活。但是这类架构不是没有需要注意的地方。IO请求量如果非常大存储层的读带宽会成为新的计费点这一点需要结合业务实际估算。另外传统架构本地NVMe在极致单线程延迟上依然有优势如果业务对单次请求延迟极度敏感、容量固定、没有扩展需求传统架构可能是更直接的选择。6.3 技术选型建议不要只看官方数据自己跑一轮这轮测试做完之后我给自己的结论是存算分离架构不是营销概念它在写密集、高并发、需要弹性扩展的场景下确实有实打实的优势。但我也要提醒大家任何人的测试数据都不能代替你自己的实际评估。不同业务的数据规模、热点分布、读写比例、SQL复杂度都不一样从我这篇测试里能看到的是方法、趋势和原理但你自己的技术选型还是应该用一套标准化的Benchmark在自己的业务模型下跑一轮。做选型评估时建议按以下清单执行数据量定为未来3年的预期值读写比例按业务高峰期统计压测并发数要高于实际峰值预热时间不少于10分钟每个场景至少跑3轮取平均重点看P99延迟和QPS的对应关系最后把运维成本、存储成本、弹性能力一起纳入评估而不是只看单台性能数字。跑完一轮完整测试后你会发现架构没有绝对的好坏只有合适与否。存算分离在写密集、弹性扩展、成本优化上的优势在测试数据里一目了然如果你的业务对这些点不敏感传统架构也有它的用武之地。关键在于数据要先于结论实测要先于选择。
PolarDB存算分离架构与传统MySQL基准测试：性能差距从哪来？
最近把PolarDB的存算分离架构和传统自建MySQL架构拉到同一个擂台上完整跑了一轮Benchmark。这轮对比测试前前后后折腾了两周中间踩了不少坑也修正过好几轮测试方案最后拿到一批比较干净的数据。这里把测试思路、环境设计、实测结果以及数据分析全部整理出来给正在纠结“云原生数据库到底行不行”“存算分离是不是营销概念”的朋友一个参考。先交代一下这份内容适合谁。如果你正面临数据库架构选型或者你在给现有业务评估是否要迁移到PolarDB这类云原生数据库又或者你只是想搞明白传统主从架构和存算分离架构的性能差异到底来自哪里这篇文章应该都能给你提供一些可落地的判断依据。测完这一轮我对“存算分离是纸面优势还是实际价值”这个问题有了非常具体的答案下面逐步拆开说。1. 先把两个架构摆清楚存算分离与传统架构到底在比什么1.1 传统架构的IO路径与性能瓶颈我口中的“传统架构”指的是最经典的自建MySQL部署方式一台物理机或者云主机数据落在本地NVMe SSD或者网络云盘上主库负责读写再用异步复制或者半同步复制搭一个或多个备库。这套架构是最成熟的绝大多数互联网公司跑了很多年踩坑经验也最丰富。传统架构的写路径是这样的应用发来一条UPDATE语句MySQL内核先更新Buffer Pool里的数据页然后写redo log写binlog事务提交时还要把redo log fsync到磁盘。如果开启了doublewrite还要处理doublewrite buffer。数据页本身则由后台线程在适当时机刷到磁盘。这个路径上任何一个环节出问题都会直接拉高写入延迟。更关键的是在主从架构下主库写完binlog后要把binlog通过网络传输给备库备库再通过SQL线程回放。这个复制链路引入了额外的延迟窗口半同步复制虽然能缓解数据丢失问题但会进一步延长主库提交的等待时间。备库回放慢了读写分离场景下就会出现“主库写入马上查不到”的数据不一致问题这也是传统架构最让人头疼的地方之一。1.2 存算分离架构的核心差异PolarDB的存算分离架构把计算和存储彻底拆开了。计算节点只负责SQL解析、执行计划生成、事务处理和Buffer Pool缓存不再持久化数据文件。数据全部存放在底层的分布式共享存储PolarStore上计算节点通过网络访问。这里最核心的变化在于写路径。PolarDB的计算节点不再需要把数据页刷到本地磁盘而是把redo日志通过专用网络发送到存储节点由存储节点侧完成日志回放和数据页合并。也就是说计算节点只需要保证日志成功写入PolarStore并返回确认事务就能提交。它省掉了一大批本地磁盘操作写放大被大幅压缩性能上限自然不一样。计算和存储之间用的是RDMA网络不是普通的TCP/IP。RDMA的优势是低延迟、低CPU开销数据在内核里可以直接绕过性能表现跟本地NVMe设备的差距被缩得非常小。再加上ParallelRaft协议在存储层做多副本同步数据的一致性和持久性由存储层保证计算节点之间则通过共享存储天然实现数据可见。1.3 为什么要把两者放在一起对比传统架构的性能瓶颈在于“每一份数据都要在本地落盘、再在网络上复制”PolarDB这类存算分离架构的性能逻辑则是“日志只写一次数据由存储层兜底”。这两者优化路径完全不同如果不做一轮控制变量的实测单纯看云厂商提供的规格参数很难直观理解性能差异的真实来源。做对比测试时我给自己定了一个原则除了“架构”这个变量本身其他条件尽量保持一致。CPU规格、内存大小、数据量、并发模型、参数配置能对齐的全部对齐。不然测出来的差距到底是架构差异还是配置差异根本说不清。2. Benchmark方案设计测什么、怎么测、用什么工具2.1 工具选型为什么用SysBench这次测试我选的是SysBench 1.0.20没有选TPC-C类工具。原因很简单SysBench是OLTP场景压测的事实标准插件化设计能精准控制并发数、测试时长、事务模型结果容易重复验证。TPC-C这种工具更贴近真实业务形态包含商品、订单、库存等多表事务但配置成本实在太高需要建库、导入数据、调整事务权重一轮跑下来光是排查环境问题就要花很多时间。第一轮架构对比我更关心的是数据库引擎在不同读写模型下的基础能力SysBench的oltp_read_only、oltp_read_write、oltp_write_only、oltp_point_select这几个脚本已经足够覆盖。SysBench的常用命令大概是这样的sysbench --db-drivermysql \ --mysql-host127.0.0.1 \ --mysql-port3306 \ --mysql-userbench \ --mysql-passwordbench123 \ --mysql-dbsbtest \ --tables10 \ --table_size5000000 \ --threads128 \ --time600 \ --report-interval10 \ oltp_read_write run参数含义也很直白10张表每张500万行总共约5000万行数据量大概是10GB左右。这个数据量能把Buffer Pool跑热测试结果更能反映CPU和IO路径的真实能力而不是冷数据读盘的极端场景。2.2 测试环境与规格说明测试环境我准备了三组尽量把差异性控制在架构本身架构计算规格存储配置部署方式传统架构A8核64GBESSD云盘PL1云主机单机部署传统架构B8核64GB本地NVMe SSD x2物理机单机部署PolarDB8核64GB x21主1只读PolarStore共享存储存储与计算分离部署传统架构A模拟的是大部分企业用云主机的场景存储走网络云盘IOPS有上限传统架构B模拟的是追求极致性能的自建机房场景用本地NVMe性能释放最彻底。PolarDB则是标准的存算分离部署计算节点规格对齐前两组。软件版本方面传统架构用的是MySQL 8.0.34PolarDB使用兼容MySQL 8.0的版本。关键参数统一调整innodb_buffer_pool_size设置为48GBinnodb_flush_log_at_trx_commit1sync_binlog1max_connections2000。这样能保证事务持久性的语义一致不会出现“为了让PolarDB更好看而故意调低传统架构参数”这种不公平对比。测试机和数据库服务器在同一内网用千兆以上网络连接PolarDB计算节点与PolarStore之间的RDMA网络由产品侧自动配置。2.3 测试场景与指标口径场景分为四组只读、写入、读写混合、高并发P99观测。每个场景先预热10分钟再正式压测10分钟取3次结果的平均值。预热非常关键目的是让Buffer Pool达到稳定状态避免冷数据导致测试结果失真。指标重点看四个QPS、TPS、平均延迟、P99延迟。QPS代表吞吐能力P99延迟代表系统在压力下的稳定性和毛刺情况。很多测试只给平均延迟这个指标其实掩盖了长尾问题——数据库在高负载下抖动非常常见P99能更真实地反映用户体验。3. 实测数据全景三组架构的对比结果3.1 只读场景核心查询能力的对比先看128并发下oltp_read_only的测试数据架构QPS平均延迟(ms)P99延迟(ms)传统架构A云盘46,8215.519.87传统架构B本地NVMe61,3474.197.26PolarDB主节点69,5283.716.05PolarDB 1主1只读118,4362.175.33只读场景下PolarDB主节点比本地NVMe部署的传统架构高了约13%只读节点加进来后整体吞吐接近翻倍。原因不难理解只读查询的主要开销是CPU执行计划和Buffer Pool访问PolarDB计算节点的本地缓存命中率和CPU调度与物理机相当再加上架构优化单节点吞吐确实更占优。传统架构A的数据也比较意外云盘在128并发只读时并没有被IOPS限制拖垮因为数据全部在内存中命中磁盘并没有成为瓶颈。这也说明一个道理如果Buffer Pool能装下全部热数据网络存储和本地存储的差异会被内存掩盖这时候性能差距更多来自引擎本身和网络协议栈的优化。3.2 写入场景IO路径差异的放大镜高并发写入是最能体现架构差异的场景。我用oltp_write_only和oltp_read_write分别做了测试128并发结果如下架构写入QPS读写混合QPS传统架构A云盘12,64217,865传统架构B本地NVMe19,83125,394PolarDB主节点28,97533,628写入场景的差距比只读大得多。PolarDB主节点比本地NVMe的传统架构高出约46%比云盘部署高出一倍多。这才是存算分离架构真正的价值所在——它不是靠单机硬件堆出来的性能而是通过精简IO路径实现的整体提升。为什么写入会有这么大差距传统架构写一次事务要经历redo log fsync、binlog fsync、doublewrite刷盘、数据页异步刷盘等多个环节任何一个环节的延迟都叠加在事务提交路径上。PolarDB的计算节点只需要把redo日志通过RDMA发送到PolarStore存储节点收到日志并完成多数派确认后即可返回成功本地不再有fsync等待。这条路径变短之后写延迟的基数大幅下降吞吐自然就上去了。3.3 高并发下的P99延迟表现并发从128提升到256和512时三组架构的表现开始明显分化。架构256并发 P99(ms)512并发 P99(ms)传统架构A云盘18.6243.75传统架构B本地NVMe14.1831.24PolarDB主节点10.4518.76最值得关注的是PolarDB在512并发下P99还在20毫秒以内而传统架构A已经飙升到43毫秒。这里面有一个很重要的细节传统架构在高并发下线程调度、锁竞争、IO队列深度会同时恶化任何一个环节出现瓶颈都会引发明显的长尾延迟。PolarDB因为写路径短、IO等待少整体越到高并发越稳。不过这里要说清楚P99表现也跟测试客户端的规格有关。我们当时用的是16核32GB的压测机512并发时客户端本身的CPU已经接近70%了。如果压测机性能不足会直接把客户端瓶颈算进数据库延迟里导致数据失真。这一点后面详细讲。3.4 横向扩展后的整体吞吐对比把只读场景扩展到2个节点对比架构1节点QPS2节点QPS扩展比传统架构B本地NVMe主从61,34798,2261.60PolarDB1主1只读69,528118,4361.70传统架构从1节点扩展到2节点用的是主从复制备库要先把主库的binlog拉过来再回放。只读流量打到备库上时备库需要消耗CPU做回放这会和查询请求互相抢占资源扩展比很难做到线性。PolarDB的只读节点共享同一份存储没有本地数据拷贝过程也不需要回放binlog它只需要在共享存储之上提供缓存和计算能力所以扩展比更高节点加得越多优势越明显。这也解释了为什么很多互联网公司在业务高峰期会临时给PolarDB加只读节点用完再缩掉——因为新节点秒级拉起不需要等待数据拷贝完成。4. 性能差距背后的原理为什么存算分离能打4.1 写路径重构一条日志走天下的含金量数据库写入的本质是“把变更记录下来保证不丢”。传统架构的做法是把变更同时记录到redo log和binlog还要把数据页本身刷到磁盘三重保障分别落在不同的文件上每个文件都有各自的fsync等待。PolarDB的做法完全不同。计算节点把变更打包成redo日志通过RDMA网络发送到PolarStore存储节点存储节点在多个副本之间确认持久化之后返回成功。数据页的合并、落盘、多副本同步全部在存储层完成计算节点对这些过程无感。用一个生活化类比传统架构是每个人写完文件都要亲手跑到档案室把原件放进A柜、复印件放进B柜、索引卡放进C柜每一步都要等管理员盖章确认PolarDB是前台统一收件收完直接放进统一的智能档案柜档案柜自己负责多副本备份和归档整理前台收到“已收妥”的确认就能去接待下一个客户了。前台计算节点的负担自然小得多。4.2 存储层多副本与一致性协议PolarStore的多副本一致性靠ParallelRaft协议来保证。和传统主从复制的异步/半同步模式相比ParallelRaft的设计目标是在保证多数派一致的前提下把日志同步的并行度做高同时降低同步延迟。传统半同步复制为什么慢因为主库要等备库返回ack才提交备库的回放线程是单线程的或者多数情况下是串行处理一个个事务主库等待网络往返加上备库落盘的时间延迟天然就上去了。PolarStore这边数据日志被拆分成多个分片并行处理单条路径的写入不阻塞其他路径整体链路更短。此外因为存储层已经保证了多副本一致计算节点之间共享数据主节点故障时备用计算节点直接挂载同一份存储完成接管不需要再等数据同步到新节点。这也是存算分离架构在故障切换场景下比传统架构快一个数量级的原因。4.3 缓存与共享存储的组合读放大被消除很多第一次接触存算分离的人会问数据都不在本地了读操作不是应该更慢吗实测数据给出的答案是并不会。原因在于计算节点保留了完整的Buffer Pool缓存读操作先走本地内存命中率足够高的情况下大多数读请求根本不会触达存储层。真正会发生存储访问的是缓存未命中的读请求。这时候PolarDB需要从PolarStore通过网络读取数据页。RDMA网络的单次往返延迟已经非常低加上数据页的读取是精细化的按需读取而不是把整个文件拉过来实际感知到的延迟并不高。传统主从架构反而是读放大很严重的场景——备库收到查询请求如果Buffer Pool没有命中就要回本地磁盘读页主库的Buffer Pool明明有这份数据却没法直接“借”给备库。存算分离天然解决了这个问题所有计算节点共享存储缓存未命中时都向PolarStore请求数据页而PolarStore的热点数据本身也有缓存加速机制整体的读命中效率更高。5. 测试过程中踩过的坑与排查实录5.1 压测工具本身成了瓶颈第一次跑512并发的时候数据出来了但怎么看怎么不对劲P99飙到50毫秒以上QPS却几乎没涨。我第一反应是数据库不行后来仔细排查发现压测机自己先扛不住了。SysBench是单进程多线程模型512并发时线程切换和锁开销非常严重加上压测机同时还在采集监控数据CPU直接打满。后来我把压测机换成更高规格的机型并做了两步优化一是给SysBench进程绑定CPU核心减少调度抖动二是开启--report-interval10每隔10秒输出一次中间指标方便观察时间维度上的变化趋势。这里给大家一个建议压测之前先确认压测机CPU使用率不超过50%网络带宽也没有打满。如果压测端先到瓶颈测出来的延迟数据就是错的这个错误还会被误判为数据库性能问题。5.2 网络类型不一致导致结果失真PolarDB第一轮只读测试的数据很不好看主节点QPS只有4万多比本地NVMe还低这与我的预期完全不符。后来检查网络发现压测客户端和PolarDB计算节点虽然在同账号同VPC下但安全组策略把RDMA链路给挡了一部分数据走的不是预期的低延迟路径。这个经历告诉我们测试存算分离架构前一定要先确认网络链路。最简单的验证方法是用ping测试计算节点与存储节点之间的延迟如果是跨可用区或者有防火墙策略延迟会飙到几毫秒甚至更高这会让存算分离架构最核心的低延迟优势荡然无存。另外一个容易忽略的点是不要把PolarDB的“本地缓存”理解成“本地磁盘”。计算节点重启后Buffer Pool是空的如果直接跑测试读请求全部穿透到存储层数据看起来会非常难看。测之前一定要做预热或者依赖SysBench执行过程中的缓存自热前几分钟的数据丢弃不要计入统计。5.3 参数调优差异造成的“不公正对比”这个问题在传统架构上尤其严重。MySQL默认配置下innodb_buffer_pool_size只有128MBinnodb_flush_log_at_trx_commit1了很多场景没开binlog也没开。用默认参数跑出来的数据和经过完整生产参数调优的数据库比性能差距会达到好几倍。为了保证对比公平我做了一张参数对齐表把三组环境的参数逐项确认过Buffer Pool大小、日志刷盘策略、binlog开关、并发线程上限、IO相关的innodb_io_capacity、innodb_flush_method全部保持一致。参数对齐这个环节没有捷径可走每一项都要确认到位不然结果没法解释。5.4 常见问题速查表问题现象可能原因排查与解决高并发下QPS不涨、P99飙升压测客户端CPU打满提高压测机规格、绑定CPU、减少监控干扰PolarDB只读性能远低于预期网络未走RDMA链路或未预热检查网络延迟、执行预热脚本后再测试传统架构表现极端差MySQL参数未调优对照生产参数逐项调整后再对比多次测试结果波动大冷热数据不一致、后台任务干扰每轮测试前重启实例丢弃前几分钟数据多轮取平均写入性能数据差异巨大事务持久性配置不一致确认flush_log_at_trx_commit、sync_binlog参数一致只读节点加入后吞吐不升反降只读节点规格过小或网络带宽受限确认只读节点CPU/内存规格检查网络带宽6. 存算分离的影响范围性能对比之外它改变了什么6.1 对DBA日常运维的改变存算分离架构带来的改变远不只在Benchmark数据上。对DBA来说日常运维的工作重心会发生明显迁移。传统架构下DBA最大的日常焦虑是主从复制延迟。备库回放慢、网络抖一下、大事务上来了延迟监控就开始告警读写分离业务随之出现主从不一致。PolarDB因为只读节点直接挂在共享存储上没有binlog回放这个环节复制延迟的概念被大幅弱化。DBA不需要再花大量时间处理复制中断和延迟问题。备份恢复的体验也完全不同。传统架构做物理备份动辄几个小时的备份窗口恢复时要重新搭实例、导数据PolarDB的备份是在存储层做快照秒级完成恢复时直接基于快照创建新实例分钟级就能拉起一个完整的环境。对于需要经常做数据恢复演练的团队这个效率提升非常可观。6.2 对应用架构与成本规划的影响存算分离对应用架构的影响最重要的是“读写分离的灵活性”。传统架构下要加一个只读副本先要申请机器、搭主从、等数据同步完成整个过程几十分钟到几小时不等。PolarDB加只读节点是分钟级别的操作用完还能释放这让“弹性伸缩”真正在数据库层面落地了。成本方面要算两本账。第一本是存储账传统主从架构下主库和备库各存一份完整数据两倍的存储成本加上备份又是一份PolarDB的存储是共享的不管加多少个只读节点底层只有一份PolarStore数据存储成本明显下降。第二本是计算账PolarDB的计算节点按规格付费如果业务对CPU要求不高最小规格起步后续按需升配比传统架构更灵活。但是这类架构不是没有需要注意的地方。IO请求量如果非常大存储层的读带宽会成为新的计费点这一点需要结合业务实际估算。另外传统架构本地NVMe在极致单线程延迟上依然有优势如果业务对单次请求延迟极度敏感、容量固定、没有扩展需求传统架构可能是更直接的选择。6.3 技术选型建议不要只看官方数据自己跑一轮这轮测试做完之后我给自己的结论是存算分离架构不是营销概念它在写密集、高并发、需要弹性扩展的场景下确实有实打实的优势。但我也要提醒大家任何人的测试数据都不能代替你自己的实际评估。不同业务的数据规模、热点分布、读写比例、SQL复杂度都不一样从我这篇测试里能看到的是方法、趋势和原理但你自己的技术选型还是应该用一套标准化的Benchmark在自己的业务模型下跑一轮。做选型评估时建议按以下清单执行数据量定为未来3年的预期值读写比例按业务高峰期统计压测并发数要高于实际峰值预热时间不少于10分钟每个场景至少跑3轮取平均重点看P99延迟和QPS的对应关系最后把运维成本、存储成本、弹性能力一起纳入评估而不是只看单台性能数字。跑完一轮完整测试后你会发现架构没有绝对的好坏只有合适与否。存算分离在写密集、弹性扩展、成本优化上的优势在测试数据里一目了然如果你的业务对这些点不敏感传统架构也有它的用武之地。关键在于数据要先于结论实测要先于选择。