基准测试工具之你不知道的两三事 | 1.数据库基准测试工具是什么
1. 前沿 在现代信息技术的飞速发展中，数据库作为数据存储和管理的核心组成部分，其性能直接影响到应用程序的响应速度和用户体验。而我们经常会遇到以下情况： 在业务选型的过程中，我们往往需要从多款数据库产品中 选择一款 作为业务支撑产品。 在数据库研发的过程中，我们同样需要将自己 优化调整后 的数据库产品同 优化调整前 的数据库产品进行比较。
约 9 分钟阅读阅读全文
基准测试方法与实践
17 篇文章
基准测试工具之你不知道的两三事 | 2.从一次时序数据库写入测试开始
在 上一篇文章 中，我们了解了数据库基准测试工具是什么，以及它为什么会出现在数据库选型和性能优化的过程中。 但知道“要测”只是第一步。真正打开工具时，很多人马上会遇到新的问题：测试程序该怎样启动？配置文件里那么多参数先看哪个？终端最后打印出一大张表，到底应该关注什么？ 这一篇就以 IoT Benchmark 为例，完成一次最小可运行的时序
约 12 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 3.如何模拟线上写入负载
上一篇文章 里，我们已经跑通了一次 IoT Benchmark 的默认写入测试，并学会了从吞吐量、失败数和 P99 延迟中读出一轮测试的基本情况。 不过，默认配置只能证明工具能够运行，不能自动代表你的业务。现实中的设备有多少？每个设备有多少测点？数据是稳定上报还是集中补传？一条请求会写入多少行？这些问题不先回答，再精确的测试也只是在测一份
约 13 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 4.如何读懂测试结果波动
在 上一篇文章 中，我们把线上写入场景拆成了设备规模、上报节奏、批写、乱序和峰值等可配置的负载要素。完成这一步后，往往会遇到一个更让人困惑的现象：明明没有改配置，同一套测试多跑几次，吞吐量和延迟却并不完全一样。 这并不意味着测试失去了价值。恰恰相反，波动本身就是系统在告诉我们：结果不能只靠一轮测试、一个最大数字或一张截图来解释。 这一篇继
约 10 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 5.什么是读写混合负载
前面的写入负载测试 ，回答的是一个很基础的问题：当设备持续上报数据时，数据库能否稳定地把数据接收下来。 但在线上环境中，写入通常不是唯一发生的事情。设备持续上报的同时，运维页面要刷新最新状态，趋势图要展示一段时间内的曲线，告警系统还可能统计某些指标。写入与读取在同一段时间内共同发生，这就是读写混合负载。 它并不意味着“把所有查询都打开”。
约 8 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 6.如何模拟线上读写混合负载
上一篇文章 中，我们介绍了读写混合负载为何不能只看纯写或纯读结果；在此之前，我们已经跑通了写入测试，并把线上设备的上报节奏、批写、乱序和峰值翻译成了写入负载。 但真实系统往往不会在写入时完全停止读取。设备持续上报的同时，仪表盘要刷新最新状态，值班人员会查看一段时间内的趋势，告警服务也可能触发聚合统计。此时，只测纯写入已经不足以回答“线上运
约 15 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 7.怎样做一场公平的性能对比
前面的文章 中，我们已经能够构造纯写和读写混合负载，也知道单次结果不能轻易代表系统能力。接下来就到了基准测试最容易产生误解、也最有实际价值的一步：比较。 比较两个数据库版本、两种写入接口，甚至两款数据库时，真正的问题不是“谁的吞吐量更大”，而是“这两个结果是否真的在回答同一个问题”。如果工作负载、硬件、配置或运行过程不同，数字再漂亮也无法
约 10 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 8.怎样找到并发与批大小的合理区间
上一篇文章做完公平的性能对比后，很多人会立刻追问：把客户端并发和批大小调到多大，才能得到最好的性能？ 这个问题没有脱离场景的固定答案。并发过低，机器可能没有被充分利用；并发过高，客户端、网络或服务端会开始排队。批次太小，请求开销占比变大；批次太大，单次等待、内存占用和尾部延迟又可能升高。真正要找的不是一个“最大数字”，而是在当前业务约束下
约 11 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 9.如何模拟乱序写入
顺序写入通常是时序数据库最容易处理的路径：同一条序列持续写入递增的时间戳。网络抖动、异步链路或边缘缓存则可能让较早的时间戳晚于新数据抵达。 IoT Benchmark 的“乱序”并不是把一批记录随机打散后直接发送。阅读它的实现会发现：工具先根据一个 stepOffset 生成记录，再在生成 时间戳 时按模式改写这个 offset。理解这条
约 13 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 10. 不同写入接口该怎样比较
同一套数据库，可能同时提供 JDBC、REST、Session 等多种写入接口。它们看起来只是“换一条调用路径”，实际却可能经过不同的序列化方式、连接管理策略和批处理实现。 因此，比较接口并不是为了给它们排一个绝对名次，而是回答一个更具体的问题： 在同一份数据、同一种写入语义和同一套资源条件下，哪种接口更适合当前业务的目标？ 这一篇以 I
约 11 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 11. 性能测试与正确性验证有什么区别
一轮基准测试结束后，我们通常最先看到的是吞吐量、平均延迟、P99 和失败数。如果吞吐足够高、失败数又是 0，能否直接说明测试通过？ 不能。性能测试回答的是“系统处理得多快”，正确性验证回答的是“系统处理的结果是否符合预期”。一次请求返回成功，只能说明客户端收到了一次成功响应，并不能自动证明所有数据都以正确的设备、时间戳、类型和值落入数据库
约 12 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 12. 单机测试与集群测试有什么不同
前面的文章中，我们已经讨论了怎样验证正确性、比较接口和寻找合理的并发区间。接下来把数据库从单机换成集群，是不是只要增加节点，再把客户端数乘几倍就可以了？ 并不是。单机测试主要观察一台服务器上的 CPU、内存、磁盘和数据库执行路径；集群测试还会引入网络、请求路由、数据分片、副本写入和节点间负载均衡。此时，测试结果不仅由数据库“单节点有多快”
约 12 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 13. 怎样保存和复盘一轮测试
基准测试最令人遗憾的结果，不是吞吐量低，而是几天后再看那张截图，已经说不清它来自哪个版本、哪份配置和哪台机器。 性能结果天然依赖上下文。同样的吞吐量，可能来自不同设备数、批大小、接口、数据库参数和硬件状态；同一个 P99 峰值，也可能对应客户端 GC、网络抖动、服务端合并或磁盘写满。没有原始证据，复盘只能变成猜测。 这一篇讨论怎样把一次
约 14 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 14. 一份可复用的基准测试方案模板
走到这里，我们已经讨论了写入、读写混合、乱序、接口、正确性、单机与集群，也知道一轮结果应该怎样保存。真正开始测试时，仍然可能面对一个现实问题：这些原则怎样组织成一份可以执行的方案？ 一份好的测试方案不是参数清单，而是一份实验契约。它提前规定要回答的问题、唯一变量、固定条件、正确性门禁、运行矩阵和结论边界。这样，无论执行者是谁，最后得到的结
约 14 分钟阅读阅读全文
基准测试工具之你不知道的两三事 | 15. 端到端案例：如何完成一次时序数据库选型
前十四篇文章分别解决了一个局部问题：怎样构造负载、读懂波动、进行公平比较、验证正确性、测试集群并保存结果。到了真正的数据库选型现场，这些方法必须被组织成一条决策链。 选型不是寻找一个脱离场景的“最快数据库”，而是判断哪个候选在当前业务约束下更合适。最高吞吐量可能伴随不可接受的 P99、资源成本或正确性问题；功能最丰富的产品也可能让部署和运
约 18 分钟阅读阅读全文
基准测试工具之你不知道的两三事｜系列目录
本系列围绕一个目标展开：把“跑出一组性能数字”逐步变成“能够支持版本回归、产品选型和系统调优的测试结论”。 当前 CSDN 专栏已发布第 1–14 篇；第 15 篇仍是本地成稿，尚未上线。 主线是： 建立可信基线 → 模拟真实负载 → 做公平比较 → 沉淀可复用方法 。 第一阶段：从工具到写入基线 序号 文章 状态 解决的问题 1 1.
约 4 分钟阅读阅读全文
怎样让基准测试更像业务：用 IoT Benchmark 设计写入工作负载
🧭 怎样让基准测试更像业务：用 IoT Benchmark 设计写入工作负载 上一篇文章里，我们已经跑通了一次 IoT Benchmark 的默认写入测试，并学会了从吞吐量、失败数和 P99 延迟中读出一轮测试的基本情况。 不过，默认配置只能证明工具能够运行，不能自动代表你的业务。现实中的设备有多少？每个设备有多少测点？数据是稳定上报还
约 13 分钟阅读阅读全文