HammerDB六库TPC-C横向对比：从跑分读数到选型决策

数据库选型这件事最怕的就是拿一张跑分表当决策依据。我用 HammerDB 做过不少轮横向对比六个主流关系型数据库放在同一套硬件上跑 TPC-C结论经常和厂商宣传、社区口碑对不上有的库单看峰值很漂亮稳态却掉得厉害有的库 NOPM 不高但延迟曲线平得像一条直线放到真实业务里反而更省心。HammerDB 支持六大数据库的对比测试难点从来不是把测试跑起来而是测试结果如何解读——同一份数字会读的人能看出瓶颈在哪一层不会读的人只能得出甲比乙快 30%这种经不起追问的结论。这篇就把我踩过的坑、用的对齐清单、以及读数的四层框架摊开讲适合已经能跑通 HammerDB、但对着结果窗口发愁的同行也适合刚接手选型评估、需要一套可复现方法的人。1. 先对齐计量口径HammerDB 的 NOPM 到底代表什么很多人第一次看 HammerDB 的结果窗口注意力全在最后那个 NOPM 数字上然后直接截图发群里。这个习惯很危险因为 HammerDB 给出的不是一个性能分数而是一组带时间维度的过程数据。你不清楚它是怎么算出来的就没法判断这个数字能不能用。1.1 TPC-C 业务模型与被放大的写路径HammerDB 的 OLTP 负载复刻的是 TPC-C 的业务模型一个分销商的订单管理系统包含新建订单、支付、订单查询、发货、库存查询五类事务。这五类事务在标准里的比例大约是 45%、43%、4%、4%、4%也就是说新建订单和支付这两类写操作占了将近九成。这个比例非常关键它意味着 HammerDB 的 TPC-C 本质上是一个写密集型负载而不是很多人想象中的混合读写。为什么这一点影响读数因为写密集型负载对存储的同步写延迟极其敏感对日志子系统的压力远大于对数据缓冲区的要求。我在早期做过一次对比两台配置几乎相同的机器唯一差别是一台把日志盘放在机械盘上另一台放在固态盘上跑出来的 NOPM 差了将近四倍。如果当时不看业务模型只比数字很容易得出某个数据库写性能差的错误结论实际上是盘的问题。所以读结果的第一步是先把被测负载的画像搞清楚写占比多少、事务粒度多大、热点在哪张表。TPC-C 里最热的表是新订单表和库存表库存表还会因为仓库编号的分布产生热点行竞争这个特性在后面解读锁等待指标时会反复用到。1.2 NOPM 与 TPM 的换算关系及误用HammerDB 结果窗口里通常同时出现 NOPM 和 TPM 两个值。NOPM 是每分钟新建订单数TPM 是每分钟总事务数。按前面说的 45% 比例理论上 TPM 大约是 NOPM 的 2.2 倍。这个换算关系看起来简单但误用率极高。我见过最常见的错误是拿 A 库的 NOPM 去比 B 库的 TPM然后说A 库比 B 库慢一半。这两个指标根本不是同一个量纲。还有人拿 NOPM 直接乘以 60 再乘以 8估算日处理订单量完全忽略了真实业务的事务构成和并发特征这种推算除了好看没有任何意义。真正该做的是把两个指标放在一起看比值。如果某个库的 TPM 与 NOPM 之比明显偏离 2.2说明事务构成出了问题可能是某类事务因为锁冲突被大量回滚重试也可能是测试脚本在某个环节卡住了。这个比值本身就是一个健康度信号比绝对值更能说明问题。我在一次测试里发现某库的比值只有 1.6追下去才发现是发货事务因为批量提交策略导致大量等待调整提交批次后比值回到 2.1NOPM 也跟着涨了一截。1.3 为什么同一个库两次跑分能差一倍同一套环境、同一个库、同样的参数跑两次结果差一倍这事我遇到过不止一次。原因通常不在数据库而在测试过程本身。第一是预热。HammerDB 启动后会先跑一段时间的 rampup这段时间内缓冲池还在填充、执行计划还在生成、连接还在建立吞吐是爬坡状态。如果你的统计窗口把 rampup 也算进去了平均值会被严重拉低。正确做法是等曲线进入平台期之后再开始计时或者干脆把 rampup 时间设得足够长让统计窗口完全落在稳态区间。第二是检查点。HammerDB 有一个检查点间隔参数默认会周期性触发数据库的检查点动作。检查点期间会有大量脏页刷盘吞吐会出现规律性的凹陷。如果测试时长刚好是检查点间隔的整数倍凹陷被平均掉如果不是某一次测试可能恰好踩在凹陷里数字就难看了。我一般会把测试时长设成检查点间隔的整数倍并且在结果曲线上确认没有明显的周期性抖动。第三是后台任务。PostgreSQL 的自动清理、MySQL 的刷脏线程、SQL Server 的惰性写入器这些后台任务在测试期间的行为会直接干扰吞吐。不把这些任务的状态控制住两次测试的差异可能比两个数据库之间的差异还大。2. 六套库拉到同一条起跑线环境对齐清单横向对比最容易翻车的地方不是测试本身而是六套环境根本没对齐。硬件差一档、文件系统不一样、内核参数没调、数据装载方式不同任何一项都会让结论失真。我现在的习惯是先列一张对齐清单六套环境逐项打勾全部通过才开始跑。2.1 硬件、操作系统与应用层的统一硬件层面要求同型号、同数量、同插槽位置的内存条和硬盘这一点听起来是废话但真有人拿两台不同代的机器做对比。更隐蔽的是存储配置六套库如果有的用独立日志盘、有的日志和数据混放写路径的差异会直接体现在结果里。我的做法是统一分成数据盘、日志盘、临时盘三块六套库按同样的方式挂载文件系统统一挂载参数统一。操作系统层面要统一内核版本和关键参数。文件句柄上限、内存过量提交策略、透明大页开关、IO 调度器这四项必须一致。透明大页尤其容易被忽略它对某些数据库的延迟影响能达到两位数百分比。我一般会关掉透明大页把 IO 调度器统一设成适合固态盘的模式然后把六套环境的参数快照存档出了问题可以回溯。应用层指的是 HammerDB 客户端本身。客户端不要和数据库抢同一台机器的资源最好独立部署。客户端到数据库的网络链路要一致延迟差异控制在毫秒级以内。如果六套库分布在不同网段先测一遍网络往返时间差异超过阈值就换机器否则你测的是网络不是数据库。2.2 warehouse 数量与虚拟用户的配比换算HammerDB 的 TPC-C 用仓库数量来定义数据规模一个仓库大致对应十万件商品、十万条库存、三万客户、三十万订单行数据量在百兆级别。虚拟用户数则代表并发终端数。这两个参数不是随便填的它们之间有一个经验配比每十个仓库对应一个虚拟用户比较接近真实业务的争用强度。仓库太少、用户太多热点行竞争会被极度放大测出来的是锁性能不是综合性能仓库太多、用户太少数据分布太散缓存命中率虚高测出来的数字好看但不真实。我一般会按目标数据量先定仓库数再按一比十左右定虚拟用户数然后做一轮小规模预跑看锁等待占比是否在合理区间。如果锁等待占总等待时间的比例超过三成说明争用过强要么加仓库要么减用户。这个预跑步骤很多人跳过直接上正式测试结果曲线一塌糊涂回头重跑浪费的时间更多。还有一个参数叫使用全部仓库打开后虚拟用户会均匀分布到所有仓库上。这个选项在仓库数远大于用户数时意义不大但在仓库数接近用户数时影响很大务必在六套环境里保持一致否则分布策略不同热点分布就不同。2.3 数据装载方式对后续测试的隐性影响建库阶段的数据装载方式会通过索引碎片、统计信息、页填充度这几个途径影响后续的测试结果而且影响会持续整个测试周期。Oracle 用直接路径装载、SQL Server 用批量复制、PostgreSQL 用 COPY、MySQL 用批量导入、Db2 用装载工具这些工具的默认行为各不相同。有的会重建索引有的不会有的会更新统计信息有的需要手动触发有的按顺序填充页有的随机填充。如果不做统一处理六套库的物理数据布局差异可能很大。我的做法是装载完成后统一做三件事重建或整理所有索引、更新全库统计信息、检查页填充度是否在合理区间。这三步做完再开始测试能消除大部分装载差异。另外装载完成后的第一次全表扫描会触发大量物理读所以正式测试前要跑一轮预热把热数据读进缓冲池否则第一分钟的曲线会非常难看。3. 六个数据库的建库与驱动差异逐个拆HammerDB 对六个库的支持程度不一样有的开箱即用有的要折腾半天。这一节把每个库在建库和驱动层面的关键差异拆开讲这些都是影响结果可比性的实质因素不是配置洁癖。3.1 MySQL 与 MariaDB 的装载与参数这两个库的建库流程最接近都用批量导入工具装载数据但有几个坑必须提前处理。第一个是本地文件导入开关。批量导入依赖客户端读取本地文件的能力这个能力默认是关闭的不开会在装载阶段直接报错。同时还要检查文件导入目录的限制参数如果设成了空值表示禁止任意目录设成特定路径则只允许该路径。我一般会在测试环境里临时放开装载完成后立刻收回。第二个是缓冲池大小。MySQL 和 MariaDB 的缓冲池是影响 OLTP 性能的第一参数建议设成物理内存的五到七成。设得太小测试期间会持续出现物理读NOPM 上不去设得太大可能触发内存交换延迟曲线会出现尖刺。这个参数在六套库里必须按同样的比例设置不能有的给七成有的给三成。第三个是日志刷盘策略。为了追求吞吐很多人会把刷盘策略调成每秒刷一次甚至交给操作系统决定这样测出来的数字会明显偏高但牺牲了持久性。如果六套库里只有这一套这么调对比就失去意义了。我的原则是六套库统一采用兼顾持久性的配置谁也别开小灶。MariaDB 在这几个参数上和 MySQL 基本一致但它的刷脏线程行为和版本差异较大建议固定版本号不要跨小版本对比。3.2 PostgreSQL 的自动清理与 WALPostgreSQL 最大的干扰源是自动清理。TPC-C 是写密集型负载会产生大量死元组自动清理进程会在测试期间频繁启动占用大量 IO 和 CPU。如果不做处理你测出来的是数据库加自动清理的综合性能而不是数据库本身的处理能力。我的处理方式是在测试期间调整自动清理的触发阈值让它不要在高负载时段频繁启动同时把清理的休眠时间调短避免积压。测试结束后再恢复默认值。这里要注意完全关闭自动清理也不可取死元组堆积会导致表膨胀后期查询性能断崖式下跌测试后段的数字会失真。写入日志是另一个关键点。PostgreSQL 的日志刷盘由提交时的同步设置控制同步提交能保证持久性但增加延迟异步提交反过来。六套库必须统一策略。另外日志的检查点间隔和单次刷脏量要调大否则检查点期间会出现明显的吞吐凹陷前面讲过的周期性问题就是这么来的。共享缓冲区的设置逻辑和 MySQL 类似但 PostgreSQL 还依赖操作系统的页缓存所以共享缓冲区不宜设得过大一般三到四成物理内存比较稳妥剩下的留给系统缓存。3.3 SQL Server、Db2、Oracle 的日志与内存这三个商业库的架构差异更大配置项也更细但影响可比性的核心点其实就那么几个。SQL Server 的关键在于内存上限和批量装载方式。内存上限不设它会逐渐吃掉整机内存导致操作系统层面开始换页延迟飙升。批量装载要确认批量工具已启用装载批次大小要统一。另外它的检查点行为受恢复间隔参数控制这个参数直接影响检查点频率六套环境里要按相近的频率设置。Db2 的关键在于锁列表大小和日志空间。TPC-C 的并发更新很容易把锁列表撑爆一旦溢出就会走锁升级大量行锁变成表锁吞吐瞬间塌掉。日志空间同理日志满了会强制归档归档期间写入阻塞。这两个参数我一般会给得比较宽裕然后观察锁等待和日志等待指标来确认是否还有压力。Oracle 的关键在于重做日志组的数量和大小。重做日志切换过于频繁会出现检查点未完成的等待表现为吞吐的规律性抖动。我一般会给三组以上的重做日志单组大小按测试时长的写入量估算。另外它的系统全局区内存分配要合理程序全局区要给足否则连接数一多就开始报内存不足。下面这张表是我常用的关键参数对齐清单六套环境按这张表逐项填填不齐就别开始跑。配置维度MySQL / MariaDBPostgreSQLSQL ServerDb2Oracle内存主参数缓冲池占物理内存五到七成共享缓冲区占三到四成实例内存上限显式设置缓冲池按数据量比例设置系统全局区按负载分配写入持久性统一采用兼顾持久性的刷盘策略统一同步提交策略统一恢复模式统一日志缓冲策略统一提交等待策略装载工具批量导入工具COPY批量复制工具装载工具直接路径装载后台干扰项刷脏线程自动清理惰性写入器日志归档检查点与归档装载后必做重建索引、更新统计信息更新统计信息、清理死元组重建索引、更新统计信息重组表、更新统计信息收集统计信息3.4 驱动与客户端版本的一致性这一条最容易被忽略。HammerDB 连接不同数据库用的是不同的客户端库这些库的版本差异会带来额外的开销差异。比如某个库的客户端驱动新版本在批处理上有优化旧版本没有同样的数据库配置测出来能差一成以上。我的做法是固定所有客户端驱动的版本六个库各自选一个经过验证的稳定版本记录在测试报告里。测试期间不升级任何驱动也不混用不同来源的驱动包。另外客户端的连接池配置要一致连接数上限、超时时间、重试次数这些参数不一致同样会污染结果。4. 跑出来的数字按层次读吞吐、延迟、资源、一致性拿到结果之后怎么读这是整篇文章的核心。我的习惯是把结果拆成四个层次从外到内依次看任何一层出现异常就停下来先解决这一层不要急着往下比。4.1 吞吐看稳态平台而非峰值结果窗口里显示的 NOPM 是一个平均值这个平均值包含爬坡期和稳态期。真正有意义的数字是稳态平台的高度而不是平均值更不是曲线上的最高点。我一般会导出曲线数据把爬坡段切掉只统计平台段的均值、标准差和最小值。均值代表能力标准差代表稳定性最小值代表最差情况。三个数放在一起看才能判断这个库是稳定输出还是忽高忽低。举个我自己的经验有两个库的平均 NOPM 几乎一样但一个标准差很小另一个波动超过两成。放到生产环境里波动大的那个意味着高峰期可能掉到谷底业务侧的体验会非常差。只看平均值根本发现不了这个差异。另外要注意平台的持续时间。有些库在测试的前半段表现很好后半段因为死元组堆积、日志空间紧张、缓存命中率下降而掉下来平均值被前半段拉高看起来还不错。这种情况必须看整条曲线的趋势确认平台段没有向下倾斜。4.2 延迟必须和并发一起看单独看吞吐是片面的必须把延迟和并发放在一起。我一般会看三个数平均响应时间、百分之九十五分位响应时间、以及最大响应时间。平均响应时间容易被少数极快的事务拉低掩盖长尾问题。百分之九十五分位更能反映大多数用户的真实体验。最大响应时间则用来发现偶发的长阻塞。三个数里分位值最重要。如果吞吐上不去同时分位延迟很高说明系统在排队瓶颈在资源侧。如果吞吐上不去但分位延迟很平稳说明并发压力根本没给到位可能是虚拟用户数太少或者某个环节成了串行瓶颈。还有一种情况是吞吐和延迟都正常但最大响应时间出现周期性尖刺。这通常是检查点、日志切换、后台任务引起的需要结合时间点去对后台任务的执行记录。我遇到过一次尖刺每五分钟出现一次追下去发现是某个库的统计信息自动更新任务在整点触发最后调整了触发窗口才解决。4.3 资源侧证据链怎么建立光看数据库指标还不够必须建立从数据库指标到操作系统资源的证据链否则你只知道慢不知道为什么慢。我的做法是测试期间同步采集四组数据数据库侧的等待事件、操作系统侧的 CPU 使用率与 IO 延迟、存储侧的每秒读写次数与队列深度、网络侧的往返时间。四组数据按时间轴对齐任何一项指标异常都能快速定位到对应的时间点再看那个时间点上其他三项在干什么。常见的对应关系是这样的CPU 使用率饱和、等待事件以 CPU 相关为主说明是计算瓶颈IO 延迟升高、队列深度积压、等待事件以写日志相关为主说明是存储瓶颈锁等待占比高、CPU 和 IO 都不高说明是业务逻辑层面的争用网络往返时间抖动说明是链路问题。这套对应关系不是绝对的但能覆盖八成以上的情况。关键是四组数据要同时采集、同时对齐只采一组等于没采。4.4 一致性校验是结果可信的前提HammerDB 的 TPC-C 负载在标准里是有一套一致性校验的用来确认跑出来的事务确实是按业务规则执行的没有因为并发冲突产生脏数据。这个校验不做你的数字再漂亮也可能是作弊换来的。比如某个库为了追求吞吐把隔离级别调低了读到脏数据也能提交事务成功率虚高NOPM 自然好看。这种情况下测出来的数字和真实业务场景完全脱节。我在每轮测试结束后都会做一次一致性校验把校验不通过的结果直接作废。另外还会核对事务成功率和回滚率回滚率异常高说明争用严重数字不可信回滚率接近于零反而要警惕可能是校验逻辑没生效。5. 一组对照实验的复盘从曲线异常定位到参数光讲方法有点干讲一个我实际做过的对照实验。这个实验里六个库的表现差异最后追下去发现根因不在数据库本身而在一个共用的环境参数上。5.1 实验设计与基线硬件是同一台机器分时复用八核处理器、三十二吉内存、固态盘分成数据盘和日志盘。六个库分别部署每次只跑一个跑完彻底清理环境再跑下一个。仓库数统一设为二十虚拟用户数设成两百爬坡时间五分钟正式测试二十分钟检查点间隔三分钟测试时长取检查点间隔的整数倍。第一轮的结果很有意思三个库的 NOPM 在同一个区间另外三个库明显偏低偏低的那三个里有两个是大家公认的高性能选手。这个结果本身就很反常我没有急着下结论而是先去看曲线。5.2 三条曲线的分叉点偏低的三条曲线有一个共同特征前五分钟爬坡正常第六分钟左右出现一次明显的凹陷之后再也没有恢复到原来的高度而是稳定在一个较低的平台。也就是说这不是慢启动问题而是某个事件在第六分钟把系统打进了一个低效状态。第六分钟这个时间点很关键。我对照了后台任务记录发现那个时间点正好是文件系统的一次批量回写触发窗口。原来那三个库的日志写入模式更倾向于攒批攒到一定量之后集中刷盘正好撞上了文件系统的回写窗口两者叠加导致 IO 队列深度瞬间打满之后虽然恢复了但缓冲池里的热数据被挤出去了一部分命中率下降平台高度就回不去了。5.3 定位过程与验证定位过程分三步。第一步是把三个库的日志写入参数全部改成更平滑的刷盘节奏重跑凹陷消失了平台高度回到正常区间验证了假设。第二步是把另外三个库也改成同样的刷盘节奏重跑结果没有明显变化说明它们本来就不受这个窗口影响。第三步是单独把文件系统的回写参数调平不做数据库侧改动重跑凹陷同样消失进一步确认根因在文件系统与写入节奏的叠加。这个实验给我的教训是横向对比时任何一个库的异常都可能来自共用环境而不是它自身。看到反常结果第一反应应该是查环境而不是给数据库下结论。另外凹陷之后回不去这个现象特别值得警惕它说明系统进入了一个新的稳态而不是临时波动这种情况下平均值完全不能代表真实能力。6. 六种不能拿来对比的结果高频误读下面这六种情况我在别人的报告和自己的早期报告里都见过每一种都会让结论彻底跑偏。误读类型典型表现正确做法用户数不同直接比A 库两百用户跑出高 NOPMB 库一百用户跑出低 NOPM结论 A 更快按单位并发折算或统一用户数重跑测试时长过短只跑三分钟曲线还在爬坡就取平均等进入稳态平台后再计时时长覆盖多个检查点周期忽略预热第一分钟数据算进平均数字被拉低单独设预热段统计窗口只取稳态区间用 OLTP 结果推 OLAP 能力拿 TPC-C 的 NOPM 评价分析查询性能两类负载分开测指标不可互换混用不同隔离级别某个库调低隔离级别换取吞吐六套统一隔离级别校验一致性只报峰值不报稳态报告里写曲线最高点报稳态均值、标准差和最小值前三种属于方法层面的错误后面三种属于口径层面的错误。方法层面的错误靠规范流程就能避免口径层面的错误需要事先约定好写进测试方案里六套环境统一执行。我现在的习惯是在测试开始前先写一份口径说明把隔离级别、刷盘策略、统计窗口、折算方式全部写清楚跑完之后任何人都能按这份说明复算。还有一类隐蔽的误读是拿不同版本的数据库对比。某个库的新版本在某个特性上有大幅优化旧版本没有你拿新版本对别人的旧版本结论就没有意义。版本必须固定而且要在报告里写明具体版本号。7. 把跑分结论回迁生产的判断标准跑分的目的不是排名是给生产环境的配置和选型提供依据。但跑分环境和生产环境差得远直接把测试参数抄到生产上往往适得其反。这一节讲怎么把结论安全地搬回去。7.1 调优动作的优先级排序从测试里能提炼出的调优动作很多但不是每个都值得搬到生产。我的排序原则是先搬那些在测试中带来确定性收益、且风险可控的动作再考虑收益不确定的动作。收益确定、风险低的动作包括合理的缓冲池大小、合适的日志空间、必要的统计信息更新策略、索引重建。这些动作在任何环境下都是正向的搬过去基本不会出问题。收益确定但风险中等的动作包括调整检查点频率、调整后台任务的触发窗口、调整批量提交的大小。这些动作在测试环境里收益明显但生产环境的负载特征是变化的参数设死了可能在别的时段出问题。搬这类动作要配套监控设好回退方案。收益不确定、风险高的动作包括调低隔离级别、关闭持久性保证、大幅调整并发上限。这类动作在测试里能换来漂亮的数字但在生产里可能带来数据一致性问题和故障恢复问题我的建议是原则上不搬除非有非常明确的业务依据。7.2 哪些参数可以搬、哪些不能搬有一个简单的判断标准这个参数的作用是否依赖于特定的数据规模。缓冲池大小、日志空间这类参数作用和数据量强相关测试环境的数据量和生产不一样直接照搬通常偏小需要按比例放大。检查点频率、后台任务窗口这类参数作用和时间维度相关和负载的时段分布强相关测试环境是持续满负载生产环境有高低峰直接照搬会导致低谷期资源浪费、高峰期压力集中。还有一类参数完全不能搬就是那些为了测试而临时调整的参数比如临时放开的文件导入权限、临时关闭的自动清理、临时调大的锁列表。这些参数在测试结束后就应该恢复搬到生产上就是事故隐患。我自己的做法是维护一份参数迁移清单每个参数标注三件事测试值、生产建议值、迁移依据。生产建议值通常不是测试值的直接复制而是按数据量比例、负载特征做换算后的结果。这份清单会和测试报告一起归档下次做类似评估时可以直接复用。最后分享一个我踩过的坑有一次我把测试环境里一个后台任务的触发阈值直接搬到了生产测试时这个阈值能有效抑制后台干扰生产上因为数据量大了一个数量级同样的阈值导致后台任务长期不触发死元组堆积了两周才被发现查询性能已经掉了一半。从那以后凡是和绝对数据量挂钩的参数我一律按比例换算绝不直接复制。跑分给出的是一组相对关系的证据把它翻译成生产配置中间那道换算的功夫省不得。