同一套数据库可能同时提供 JDBC、REST、Session 等多种写入接口。它们看起来只是“换一条调用路径”实际却可能经过不同的序列化方式、连接管理策略和批处理实现。因此比较接口并不是为了给它们排一个绝对名次而是回答一个更具体的问题在同一份数据、同一种写入语义和同一套资源条件下哪种接口更适合当前业务的目标这一篇以 IoT Benchmark 为例讨论如何让接口比较既公平又对工程选型有用。1. 先明确你比较的是接口不是两套测试如果 JDBC 使用 10 个客户端、每次写 100 行而 REST 使用 20 个客户端、每次写 1 000 行最后比较两个吞吐量得到的并不是接口差异而是两套负载的差异。接口比较的核心是控制变量。可以把一轮测试拆成两部分应保持一致的内容可以随接口变化的内容数据库版本、部署拓扑、数据模型、设备数、测点数、时间戳规则、写入总量、客户端数、批大小、压测时长协议与驱动、请求编码、连接建立方式、接口原生支持的写入调用右侧这些变化正是接口实现的一部分应当被记录而不应被假装“抹平”。例如一个接口原生支持按 Tablet 批量写入另一个接口以 HTTP 请求承载批数据二者的封装路径不同结果自然可能不同。公平的要求不是让它们内部完全一样而是让它们面对同一业务工作量。同一业务工作量同一数据模型与数据集同一设备数、测点数与时间范围同一并发、批大小与节奏仅切换写入接口JDBCRESTSession记录吞吐、延迟、失败与资源2. “同一工作量”到底要固定什么接口对比最容易漏掉的是只固定了记录条数却没有固定一条记录真正包含什么。建议把以下内容写入测试方案并在每次运行时复核。维度需要固定的内容为什么重要数据模型设备数、每设备测点数、数据类型、标签或路径结构不同 schema 会改变元数据处理与写入放大。数据内容时间范围、时间戳精度、顺序 / 乱序比例、空值与异常值规则数据分布不同存储和编码路径也可能不同。写入语义每条记录、每设备、每批所代表的数据量是否要求幂等“一次请求”不应成为比较单位逻辑数据量才是。到达负载客户端数、批大小、写入间隔、持续时间与预热策略这些参数会直接改变连接和服务端排队压力。环境服务端版本与配置、节点规模、硬件、网络、客户端机器环境漂移会掩盖接口本身的差异。一个实用原则是以成功写入的数据点数或逻辑记录数作为工作量单位而不是以“请求数”作为唯一单位。同样 1 万条数据10 个大请求与 1 万个小请求对接口的压力完全不同。3. 用 IoT Benchmark 切换接口但不要顺手改动负载IoT Benchmark 通过DB_SWITCH选择待测数据库及连接方式。以官方 README 中列出的 IoTDB 2.x 配置为例可选择IoTDB-200-JDBC、IoTDB-200-REST、IoTDB-200-SESSION_BY_TABLET、IoTDB-200-SESSION_BY_RECORD或IoTDB-200-SESSION_BY_RECORDS等不同写入路径。这给接口对比提供了一个清晰的起点每次只变更DB_SWITCH对应的接口其余负载参数保持不变。例如设备规模、DATA_CLIENT_NUMBER、每次写入涉及的设备数、BATCH_SIZE_PER_WRITE和写入间隔都应来自同一份基线配置。# 以下参数在各接口组保持一致数值应按真实场景设定 DATA_CLIENT_NUMBER固定值 DEVICE_NUM_PER_WRITE固定值 BATCH_SIZE_PER_WRITE固定值 OP_MIN_INTERVAL固定值 # 每组只切换这一项例如 DB_SWITCHIoTDB-200-SESSION_BY_TABLET这里的“保持不变”有一个边界如果某个接口根本不支持某种批写语义不能通过额外的业务层拼装去强行模拟再宣称是在比较原生接口。应该如实记录该接口能力边界并把比较问题改写为“在相同逻辑工作量下的可用实现”而不是假装所有接口具备完全相同的调用模型。4. 先比较两个层次再解释结果单独给出峰值吞吐量往往不够回答工程问题。更有用的做法是同时给出“接口效率”和“线上代价”两个层次。层次建议观察项回答的问题接口效率成功写入吞吐量、平均 / P99 延迟、失败率在固定负载下这条接口路径能处理多少数据、是否稳定。客户端代价客户端 CPU、内存、连接数、网络流量更高的吞吐是否依赖更重的编码、更多连接或更多带宽。服务端代价CPU、内存、磁盘、网络、后台任务与错误日志性能差异来自接口侧还是已经把服务端某项资源打满。使用边界超时、重试、鉴权、错误可观测性与 SDK 成熟度这条接口能否满足实际开发和运维要求。比如接口 A 的吞吐量略高但在同一客户端资源下 P99 大幅波动接口 B 的吞吐略低却有更稳定的失败率和更清楚的错误反馈。前者不一定就是更好的线上选择。性能结论与工程选择应并列呈现而不是互相替代。5. 推荐的执行顺序从可用到可比在正式压测前每个接口都应先通过一个最小可用性检查能否连接、能否建模、能否写入预期数据以及写入结果能否被查询到。只有这些条件成立后续的性能数字才有意义。否是确定共同业务工作量为每个接口完成最小写入验证写入结果与数据模型一致修正配置或记录能力边界固定环境与负载参数随机或交替运行各接口重复多轮并保留原始日志汇总吞吐、P99、失败和资源解释差异并形成适用条件随机或交替运行的目的是减少时间因素带来的偏差。若总是先跑 JDBC、后跑 REST后一次可能已经受到了缓存、磁盘状态、后台合并或环境温度变化的影响。更稳妥的方式是轮换顺序并让每个接口都有足够的重复轮次。6. 一张结果表不要只放一个 TPS下面是一份可直接用于汇报的结果表结构。表中的数值必须来自真实运行不要把示例配置或 README 输出当作实测结论。接口数据库与驱动版本逻辑工作量吞吐量P99 延迟失败率客户端 / 服务端资源结论边界JDBC待填待填待填待填待填待填待填REST待填待填待填待填待填待填待填Session待填待填待填待填待填待填待填“结论边界”这一列尤其重要。它至少要说明该结论适用于什么数据模型、什么批大小和并发区间以及是否包含乱序或读写混合。这样读者才不会把一个特定条件下的结果外推为所有场景的定论。7. 三个常见误区第一把批大小调到各接口各自的最高点再比较。这适合回答“各接口各自的最佳实践是什么”却不适合回答“在相同业务批次下谁更快”。两种问题都值得测试但不能混在同一张排名表里。第二只看客户端报告的吞吐量。客户端发得很快不等于服务端已经稳定接收。必须同时检查失败数、超时、服务端日志和必要的结果校验。第三忽略建连与预热阶段。短时任务中连接建立、鉴权和首次请求可能占主要成本长期稳定写入中它们的占比又可能很低。报告应说明统计窗口是否包含这些阶段。8. 小结比较 JDBC、REST、Session 等写入接口关键不在于得到一个“万能第一名”而在于固定逻辑工作量和环境把协议与调用方式作为唯一主动变量并同时记录吞吐、延迟、失败和资源代价。当结果带有明确的版本、数据模型、批大小、并发和统计窗口时接口对比才会从一次跑分变成可以指导 SDK 选择与系统设计的工程证据。下一篇将讨论另一个常被忽略的问题性能测试跑得快是否就代表数据真的写对了系列文章第一篇数据库基准测试工具是什么第二篇从一次时序数据库写入测试开始第三篇如何模拟线上写入负载第四篇如何读懂测试结果波动第五篇什么是读写混合负载第六篇如何模拟线上读写混合负载第七篇怎样做一场公平的性能对比第八篇怎样找到并发与批大小的合理区间第九篇如何模拟乱序写入