dbx 项目 Apache IoTDB 驱动基准测试全指南JDBC 与 Go 客户端对比方法、配置与结果解读【免费下载链接】dbx20 MB lightweight cross-platform database client for 90 databases, including MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, SQL Server, and Dameng. Built-in AI, MCP Server, CLI, desktop and Docker. | 轻量级跨平台数据库管理工具支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、达梦等 90 数据库提供桌面端、Docker、CLI、内置 AI 助手和 MCP Server。项目地址: https://gitcode.com/gh_mirrors/dbx7/dbx本篇技术指南围绕 dbx 仓库中 agents/drivers/iotdb/bench/README.md 展开系统讲解这套独立基准测试benchmark的设计动机、四种工作负载、完整环境变量配置、运行方式与源码级实现细节并结合仓库内已有的 macOS arm64 实测数据iotdb-2.0.8-macos-arm64.json给出客观解读。读者读完可以自行复现 JDBC 与 Go 客户端在同一 Apache IoTDB 2.0.8 服务器上的对比测试也能理解为何 dbx 生产环境的 IoTDB Agent 选择了 Go 客户端作为主力实现。基准测试的背景与定位dbx 的 IoTDB Agent 模块agents/drivers/iotdb/早期基于 JDBC 实现后来整体迁移到官方 Apache IoTDB Go 客户端。本套基准测试正是那次迁移决策所依赖的对比依据它被独立保留在 agents/drivers/iotdb/bench/ 目录下用于回答一个核心问题在同样的 Tree 模型服务器与相同测试数据上Apache IoTDB 官方 2.0.8 的 JDBC 客户端与 Go 客户端在冷启动、建连、常驻内存和各类查询延迟上分别表现如何需要特别强调它的定位这是一份客户端驱动的对比client-side comparison不是 IoTDB 服务器吞吐量压测它只比较驱动本身不包含dbx 的 JSON-RPC Agent 协议层它也不证明功能与版本兼容性完全对齐那些由 integration_test.go 等生产测试负责。从源码结构看基准目录内同时保留了 Java 版 JDBC 基准、Go 版基准、Python 调度器 以及实测结果三者共同构成一套可复现的对比闭环。测试范围与核心方法论固定测试数据基准测试默认在root.dbx_bench.d1设备下准备10,000 行Tree 模型数据包含三个时间序列字段时间序列数据类型编码方式s1INT64RLEs2DOUBLEGORILLAs3TEXTPLAIN数据由 JDBC 侧负责灌入IOTDB_BENCH_MODEprepare插入时以批量方式写入默认每 500 行执行一次executeBatch()对应源码中的BENCH_INSERT_BATCH_SIZE配置每行按(time, s1row*10, s2row/10.0, s3row-n)生成。四种工作负载工作负载SQL默认迭代次数数据规模show_databasesSHOW DATABASES20元数据查询point_querySELECT s1,s2,s3 FROM root.dbx_bench.d1 WHERE time rows/21001 行单点查询range_100SELECT s1,s2,s3 FROM root.dbx_bench.d1 LIMIT 10030100 行范围查询scan_allSELECT s1,s2,s3 FROM root.dbx_bench.d15全表扫描 10,000 行四个负载恰好覆盖了元数据、精确点查、小范围查询与全量扫描四种典型访问模式其中scan_all承担最大的服务端工作量和结果解码压力10,000 行 × 3 列 40,000 个单元格。两条重要的公平性设计全量解码每个返回单元格两种客户端在计时区间内都会逐行逐列调用取值 API——Go 侧是dataset.GetObjectByIndex见 go/main.go 的executeQuery函数JDBC 侧是resultSet.getObject(column)见 JdbcDriverBenchmark.java 的executeQuery方法。也就是说测量的是取回并解码的完整链路而不是只下发 SQL 就结束。结果形状稳定性校验每次迭代都会记录返回行数与解码单元格数若同一工作负载不同轮次的结果形状不一致直接报错终止Unstable result shape防止因数据变化导致无效对比。此外每个工作负载在正式采样前都会执行若干次预热warmup默认 3 次scan_all因成本较高预热次数被限制为最多 1 次以减少缓存与 JIT 等因素对首轮数据的干扰。环境准备与依赖运行前需要准备以下环境JavaJDK参考实测环境为 Java 21.0.7用于构建和运行 JDBC 基准Go1.23bench 的 go.mod 声明go 1.23用于构建 Go 基准Apache IoTDB 2.0.8standalone 服务器Docker 或本地进程均可Python 3运行调度器run.pygradlew仓库根目录的 Gradle wrappergradlew用于构建 JDBC 基准 JAR。双方客户端均锁定在2.0.8版本JDBC 侧通过org.apache.iotdb.jdbc.IoTDBDriver加载Go 侧通过github.com/apache/iotdb-client-go/v2 v2.0.8引入见 go.mod保证同一协议版本下的可比性。启动 IoTDB 测试服务器基准测试需要一个可用的 IoTDB 实例。最便捷的方式是使用官方 standalone Docker 镜像例如docker run --rm --name dbx-iotdb-bench -p 6667:6667 apache/iotdb:2.0.8-standalone容器启动后必须等待 6667 端口就绪再开始运行基准。调度器run.py内置了端口探测逻辑wait_for_server它会以 0.5 秒为间隔重试连接默认在 60 秒BENCH_SERVER_TIMEOUT内等待服务器就绪超时则抛出IoTDB is not reachable at host:port错误。运行基准测试在仓库根目录执行python3 agents/drivers/iotdb/bench/run.py \ /tmp/dbx-iotdb-driver-benchmark.json调度器会把完整结果以 JSON 形式输出到 stdout重定向到文件后即可留存和分析。以下是run.py的内部执行流程见 run.py探测服务器等待IOTDB_HOST:IOTDB_PORT可达构建两个候选除非设置BENCH_SKIP_BUILDtrueJDBC通过仓库根目录的gradlew执行benchmarkJar任务产物为build/libs/dbx-iotdb-jdbc-benchmark.jarGo在bench/go目录执行go build -o build/iotdb-go-benchmark .重建 fixture除非BENCH_PREPAREfalse以IOTDB_BENCH_MODEprepare运行 JDBC 基准重建root.dbx_bench数据库并灌入数据冷启动采样交替顺序运行probe模式采集进程启动 建连耗时默认 5 轮常驻 RSS 采样以hold模式启动进程并保持连接用ps -o rss读取常驻内存默认 3 次正式基准轮次以benchmark模式交替运行双方默认 3 轮每轮完整跑完四种工作负载。一个容易被忽视的细节是候选顺序交替无论是冷启动、RSS 还是正式轮次每次迭代都会反转执行顺序names if iteration % 2 0 else list(reversed(names))用于抵消先运行方可能占有的系统缓存优势。四种运行模式两份客户端基准通过环境变量IOTDB_BENCH_MODE切换行为可取值模式行为用途prepare重建root.dbx_bench数据库并批量插入数据仅 JDBC 支持准备 fixtureprobe启动、建连、执行一次SHOW DATABASES后立即退出并输出 JSON测量冷启动hold启动、建连、执行一次查询后打印readyJSON 并休眠默认 30 秒测量常驻 RSSbenchmark完整跑四种工作负载并输出详细结果 JSON正式对比这些模式在 JdbcDriverBenchmark.java 的main与 go/main.go 的main中一一对应实现。配置参数详解基准的全部行为都由环境变量控制无需改动任何代码。除原 README 列出的参数外源码中还定义了若干补充参数下面一并整理。服务器连接参数环境变量默认值说明IOTDB_HOST127.0.0.1IoTDB 服务器地址IOTDB_PORT6667IoTDB 服务端口IOTDB_USERNAMEroot用户名IOTDB_PASSWORDroot密码BENCH_CONNECT_TIMEOUT_MS5000建连超时毫秒Go 侧session.Open(false, timeout)使用BENCH_QUERY_TIMEOUT_MS30000查询超时毫秒Go 侧传给ExecuteQueryStatement(sql, timeout)fixture 与采样规模参数环境变量默认值说明BENCH_ROWS10000fixture 行数BENCH_FETCH_SIZE1024每批拉取行数JDBC 与 Go 双方保持一致BENCH_INSERT_BATCH_SIZE500灌数据时的 JDBC 批量插入粒度仅 prepare 阶段BENCH_STARTUPS5冷启动采样次数BENCH_RSS_SAMPLES3常驻 RSS 采样次数BENCH_ROUNDS3正式基准轮数BENCH_ORDERjdbc,go候选执行顺序设go,jdbc可检查顺序效应BENCH_WARMUPS3每个工作负载的预热次数scan_all最多 1 次BENCH_METADATA_ITERATIONS20SHOW DATABASES采样次数BENCH_POINT_ITERATIONS100单点查询采样次数BENCH_RANGE_ITERATIONS30100 行范围查询采样次数BENCH_SCAN_ITERATIONS5全量扫描采样次数流程控制参数环境变量默认值说明BENCH_PREPAREfalsetrue设为false时保留已有 fixture跳过数据重建BENCH_SKIP_BUILDtruefalse设为true时复用已有的 JAR 与 Go 二进制跳过构建BENCH_HOLD_MS30000hold模式的保持时长毫秒BENCH_SERVER_TIMEOUT60.0等待服务器就绪的超时秒BENCH_COMMAND_TIMEOUT180.0单个子命令的执行超时秒BENCH_READY_TIMEOUT30.0等待hold模式输出ready信号的超时秒关键注意事项两个候选必须连接同一台服务器且不要在候选之间改动 fixture 或 fetch size否则对比失去意义。这是一份客户端对比切勿把它当作 IoTDB 服务端的吞吐能力基准。输出 JSON 结构解读run.py最终输出的 JSON 包含以下顶层字段与 run.py 的output构建逻辑对应server服务器地址与端口configrows、fetch_size、warmups 等生效配置artifact_bytes两个候选产物体积JAR 与 Go 二进制字节数startup_ms冷启动进程 建连样本的 count/mean/p50/p95/min/maxconnected_rss_kb常驻内存样本统计KBresults按候选分组包含建连耗时connect_ms统计与每种工作负载的round_mean_ms、round_p50_ms、round_p95_ms以及每一轮的原始明细rounds数组。每个工作负载的单轮明细形如{ name: point_query, iterations: 100, rows: 1, decoded_cells: 4, mean_ms: 0.565, p50_ms: 0.538, p95_ms: 0.788, min_ms: 0.404, max_ms: 0.86 }其中decoded_cells是判断解码成本的关键指标scan_all 为 40,000。仓库中已保存一份完整原始数据iotdb-2.0.8-macos-arm64.json。参考实测结果macOS arm64仓库自带的 results/README.md 汇总了一次真实运行结果环境为Apple M2 PromacOS arm64、Java 21.0.7、Go 1.26.5、IoTDB 2.0.8 standalone、双方客户端均锁定 2.0.8、10,000 行 Tree 数据、fetch size 1,024、15 次交替冷启动、5 次 RSS 采样、5 轮交替工作负载。指标JDBCGoGo 相对下降冷启动进程 建连p50172.612 ms9.315 ms94.6%常驻 RSS p5062,368 KB7,008 KB88.8%产物体积25,864,492 B6,475,202 B75.0%进程内建连均值66.061 ms1.932 ms97.1%SHOW DATABASES均值0.775 ms0.428 ms44.8%单点查询均值0.813 ms0.595 ms26.8%100 行查询均值1.437 ms1.010 ms29.7%10,000 行全量解码均值5.455 ms4.941 ms9.4%如何解读这份数据数据呈现出一个清晰的分层结论优势最大的维度是冷启动、内存与产物体积。Go 客户端冷启动快 94.6%JVM 启动开销消失常驻内存不到 JDBC 的八分之一62 MB → 7 MB单一二进制产物仅 6.5 MB。这三个维度直接决定了 Agent 进程的拉起速度、资源占用和分发成本——这正是 dbx 将生产 IoTDB Agent 迁移到 Go 的主要动因。建连延迟差距同样显著进程内建连从约 66 ms 降到约 1.9 ms。需要区分的是冷启动指标已包含进程拉起而connect_ms是连接建立本身的开销两者都被 Go 大幅改善。热查询差距相对温和且随工作负载加重而收窄元数据查询快 44.8%点查询快 26.8%100 行查询快 29.7%而全量扫描解码 40,000 个单元格时仅快 9.4%。这符合预期——服务端处理与结果解码的工作量越大客户端语言差异在总耗时中的占比就越小。结论方向该结果支持以 Go Agent 换取启动、建连、内存与分发体积上的收益热查询差异小到不足以成为迁移的阻碍。但正如 results/README.md 明确声明的此基准不包含dbx JSON-RPC Agent 层也不能证明功能与版本兼容性的完全对齐——那些需要依赖生产 Agent 的功能测试来保证。生产 Agent 的迁移现状源码侧佐证当前 agents/drivers/iotdb/README.md 明确说明该模块以官方 Apache IoTDB Go 客户端实现 DBX Agent 协议默认使用 Tree SQL可通过sql_dialecttable切换 Table 模型。其连接参数fetch_size、time_zone、connect_retry_max、ssl、node_urls等与基准测试中的部分配置一脉相承。值得注意的实现细节仓库将上游 Go 客户端 vendored 在 agents/go-common/iotdb-client-go 下并打了一个补丁——上游丢弃了 1.3.x 服务器的ColumnNameIndexMap回退逻辑会导致聚合结果与 SELECT 列顺序错位补丁后的客户端在缺少有序索引列表时通过服务器提供的名称索引映射值列。这说明基准测试只是决策链的一环真正的兼容性保障来自 integration_test.go 等测试可通过DBX_IOTDB_LIVE1 go test -race ./... -count1针对真实服务器运行。局限性与复现注意事项复现或引用这套基准时请留意以下边界单机单配置仓库仅保存了 macOS arm64 一组结果换到 Linux x86_64、不同 JDK/Go 版本或不同磁盘/网络环境下绝对数值必然变化相对趋势也未必完全一致客户端对比非服务器压测不要用这些数值推断 IoTDB 服务器容量不含 Agent 协议层结果不能直接代表 dbx 生产 Agent 端到端性能fetch size 一致性对比双方时务必保持相同 fetch size 与 fixture否则结论无效顺序效应默认BENCH_ORDERjdbc,go建议用BENCH_ORDERgo,jdbc复跑一轮以确认无顺序偏差。相关资源索引基准文档agents/drivers/iotdb/bench/README.md调度器实现agents/drivers/iotdb/bench/run.pyJDBC 基准实现agents/drivers/iotdb/bench/java/com/dbx/agent/iotdb/bench/JdbcDriverBenchmark.javaGo 基准实现agents/drivers/iotdb/bench/go/main.goGo 依赖声明agents/drivers/iotdb/bench/go/go.mod结果汇总agents/drivers/iotdb/bench/results/README.md原始数据agents/drivers/iotdb/bench/results/iotdb-2.0.8-macos-arm64.json生产 IoTDB Agent 说明agents/drivers/iotdb/README.md【免费下载链接】dbx20 MB lightweight cross-platform database client for 90 databases, including MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, SQL Server, and Dameng. Built-in AI, MCP Server, CLI, desktop and Docker. | 轻量级跨平台数据库管理工具支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、达梦等 90 数据库提供桌面端、Docker、CLI、内置 AI 助手和 MCP Server。项目地址: https://gitcode.com/gh_mirrors/dbx7/dbx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 dbx 项目 Apache IoTDB 驱动基准测试全指南：JDBC 与 Go 客户端对比方法、配置与结果解读
dbx 项目 Apache IoTDB 驱动基准测试全指南JDBC 与 Go 客户端对比方法、配置与结果解读【免费下载链接】dbx20 MB lightweight cross-platform database client for 90 databases, including MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, SQL Server, and Dameng. Built-in AI, MCP Server, CLI, desktop and Docker. | 轻量级跨平台数据库管理工具支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、达梦等 90 数据库提供桌面端、Docker、CLI、内置 AI 助手和 MCP Server。项目地址: https://gitcode.com/gh_mirrors/dbx7/dbx本篇技术指南围绕 dbx 仓库中 agents/drivers/iotdb/bench/README.md 展开系统讲解这套独立基准测试benchmark的设计动机、四种工作负载、完整环境变量配置、运行方式与源码级实现细节并结合仓库内已有的 macOS arm64 实测数据iotdb-2.0.8-macos-arm64.json给出客观解读。读者读完可以自行复现 JDBC 与 Go 客户端在同一 Apache IoTDB 2.0.8 服务器上的对比测试也能理解为何 dbx 生产环境的 IoTDB Agent 选择了 Go 客户端作为主力实现。基准测试的背景与定位dbx 的 IoTDB Agent 模块agents/drivers/iotdb/早期基于 JDBC 实现后来整体迁移到官方 Apache IoTDB Go 客户端。本套基准测试正是那次迁移决策所依赖的对比依据它被独立保留在 agents/drivers/iotdb/bench/ 目录下用于回答一个核心问题在同样的 Tree 模型服务器与相同测试数据上Apache IoTDB 官方 2.0.8 的 JDBC 客户端与 Go 客户端在冷启动、建连、常驻内存和各类查询延迟上分别表现如何需要特别强调它的定位这是一份客户端驱动的对比client-side comparison不是 IoTDB 服务器吞吐量压测它只比较驱动本身不包含dbx 的 JSON-RPC Agent 协议层它也不证明功能与版本兼容性完全对齐那些由 integration_test.go 等生产测试负责。从源码结构看基准目录内同时保留了 Java 版 JDBC 基准、Go 版基准、Python 调度器 以及实测结果三者共同构成一套可复现的对比闭环。测试范围与核心方法论固定测试数据基准测试默认在root.dbx_bench.d1设备下准备10,000 行Tree 模型数据包含三个时间序列字段时间序列数据类型编码方式s1INT64RLEs2DOUBLEGORILLAs3TEXTPLAIN数据由 JDBC 侧负责灌入IOTDB_BENCH_MODEprepare插入时以批量方式写入默认每 500 行执行一次executeBatch()对应源码中的BENCH_INSERT_BATCH_SIZE配置每行按(time, s1row*10, s2row/10.0, s3row-n)生成。四种工作负载工作负载SQL默认迭代次数数据规模show_databasesSHOW DATABASES20元数据查询point_querySELECT s1,s2,s3 FROM root.dbx_bench.d1 WHERE time rows/21001 行单点查询range_100SELECT s1,s2,s3 FROM root.dbx_bench.d1 LIMIT 10030100 行范围查询scan_allSELECT s1,s2,s3 FROM root.dbx_bench.d15全表扫描 10,000 行四个负载恰好覆盖了元数据、精确点查、小范围查询与全量扫描四种典型访问模式其中scan_all承担最大的服务端工作量和结果解码压力10,000 行 × 3 列 40,000 个单元格。两条重要的公平性设计全量解码每个返回单元格两种客户端在计时区间内都会逐行逐列调用取值 API——Go 侧是dataset.GetObjectByIndex见 go/main.go 的executeQuery函数JDBC 侧是resultSet.getObject(column)见 JdbcDriverBenchmark.java 的executeQuery方法。也就是说测量的是取回并解码的完整链路而不是只下发 SQL 就结束。结果形状稳定性校验每次迭代都会记录返回行数与解码单元格数若同一工作负载不同轮次的结果形状不一致直接报错终止Unstable result shape防止因数据变化导致无效对比。此外每个工作负载在正式采样前都会执行若干次预热warmup默认 3 次scan_all因成本较高预热次数被限制为最多 1 次以减少缓存与 JIT 等因素对首轮数据的干扰。环境准备与依赖运行前需要准备以下环境JavaJDK参考实测环境为 Java 21.0.7用于构建和运行 JDBC 基准Go1.23bench 的 go.mod 声明go 1.23用于构建 Go 基准Apache IoTDB 2.0.8standalone 服务器Docker 或本地进程均可Python 3运行调度器run.pygradlew仓库根目录的 Gradle wrappergradlew用于构建 JDBC 基准 JAR。双方客户端均锁定在2.0.8版本JDBC 侧通过org.apache.iotdb.jdbc.IoTDBDriver加载Go 侧通过github.com/apache/iotdb-client-go/v2 v2.0.8引入见 go.mod保证同一协议版本下的可比性。启动 IoTDB 测试服务器基准测试需要一个可用的 IoTDB 实例。最便捷的方式是使用官方 standalone Docker 镜像例如docker run --rm --name dbx-iotdb-bench -p 6667:6667 apache/iotdb:2.0.8-standalone容器启动后必须等待 6667 端口就绪再开始运行基准。调度器run.py内置了端口探测逻辑wait_for_server它会以 0.5 秒为间隔重试连接默认在 60 秒BENCH_SERVER_TIMEOUT内等待服务器就绪超时则抛出IoTDB is not reachable at host:port错误。运行基准测试在仓库根目录执行python3 agents/drivers/iotdb/bench/run.py \ /tmp/dbx-iotdb-driver-benchmark.json调度器会把完整结果以 JSON 形式输出到 stdout重定向到文件后即可留存和分析。以下是run.py的内部执行流程见 run.py探测服务器等待IOTDB_HOST:IOTDB_PORT可达构建两个候选除非设置BENCH_SKIP_BUILDtrueJDBC通过仓库根目录的gradlew执行benchmarkJar任务产物为build/libs/dbx-iotdb-jdbc-benchmark.jarGo在bench/go目录执行go build -o build/iotdb-go-benchmark .重建 fixture除非BENCH_PREPAREfalse以IOTDB_BENCH_MODEprepare运行 JDBC 基准重建root.dbx_bench数据库并灌入数据冷启动采样交替顺序运行probe模式采集进程启动 建连耗时默认 5 轮常驻 RSS 采样以hold模式启动进程并保持连接用ps -o rss读取常驻内存默认 3 次正式基准轮次以benchmark模式交替运行双方默认 3 轮每轮完整跑完四种工作负载。一个容易被忽视的细节是候选顺序交替无论是冷启动、RSS 还是正式轮次每次迭代都会反转执行顺序names if iteration % 2 0 else list(reversed(names))用于抵消先运行方可能占有的系统缓存优势。四种运行模式两份客户端基准通过环境变量IOTDB_BENCH_MODE切换行为可取值模式行为用途prepare重建root.dbx_bench数据库并批量插入数据仅 JDBC 支持准备 fixtureprobe启动、建连、执行一次SHOW DATABASES后立即退出并输出 JSON测量冷启动hold启动、建连、执行一次查询后打印readyJSON 并休眠默认 30 秒测量常驻 RSSbenchmark完整跑四种工作负载并输出详细结果 JSON正式对比这些模式在 JdbcDriverBenchmark.java 的main与 go/main.go 的main中一一对应实现。配置参数详解基准的全部行为都由环境变量控制无需改动任何代码。除原 README 列出的参数外源码中还定义了若干补充参数下面一并整理。服务器连接参数环境变量默认值说明IOTDB_HOST127.0.0.1IoTDB 服务器地址IOTDB_PORT6667IoTDB 服务端口IOTDB_USERNAMEroot用户名IOTDB_PASSWORDroot密码BENCH_CONNECT_TIMEOUT_MS5000建连超时毫秒Go 侧session.Open(false, timeout)使用BENCH_QUERY_TIMEOUT_MS30000查询超时毫秒Go 侧传给ExecuteQueryStatement(sql, timeout)fixture 与采样规模参数环境变量默认值说明BENCH_ROWS10000fixture 行数BENCH_FETCH_SIZE1024每批拉取行数JDBC 与 Go 双方保持一致BENCH_INSERT_BATCH_SIZE500灌数据时的 JDBC 批量插入粒度仅 prepare 阶段BENCH_STARTUPS5冷启动采样次数BENCH_RSS_SAMPLES3常驻 RSS 采样次数BENCH_ROUNDS3正式基准轮数BENCH_ORDERjdbc,go候选执行顺序设go,jdbc可检查顺序效应BENCH_WARMUPS3每个工作负载的预热次数scan_all最多 1 次BENCH_METADATA_ITERATIONS20SHOW DATABASES采样次数BENCH_POINT_ITERATIONS100单点查询采样次数BENCH_RANGE_ITERATIONS30100 行范围查询采样次数BENCH_SCAN_ITERATIONS5全量扫描采样次数流程控制参数环境变量默认值说明BENCH_PREPAREfalsetrue设为false时保留已有 fixture跳过数据重建BENCH_SKIP_BUILDtruefalse设为true时复用已有的 JAR 与 Go 二进制跳过构建BENCH_HOLD_MS30000hold模式的保持时长毫秒BENCH_SERVER_TIMEOUT60.0等待服务器就绪的超时秒BENCH_COMMAND_TIMEOUT180.0单个子命令的执行超时秒BENCH_READY_TIMEOUT30.0等待hold模式输出ready信号的超时秒关键注意事项两个候选必须连接同一台服务器且不要在候选之间改动 fixture 或 fetch size否则对比失去意义。这是一份客户端对比切勿把它当作 IoTDB 服务端的吞吐能力基准。输出 JSON 结构解读run.py最终输出的 JSON 包含以下顶层字段与 run.py 的output构建逻辑对应server服务器地址与端口configrows、fetch_size、warmups 等生效配置artifact_bytes两个候选产物体积JAR 与 Go 二进制字节数startup_ms冷启动进程 建连样本的 count/mean/p50/p95/min/maxconnected_rss_kb常驻内存样本统计KBresults按候选分组包含建连耗时connect_ms统计与每种工作负载的round_mean_ms、round_p50_ms、round_p95_ms以及每一轮的原始明细rounds数组。每个工作负载的单轮明细形如{ name: point_query, iterations: 100, rows: 1, decoded_cells: 4, mean_ms: 0.565, p50_ms: 0.538, p95_ms: 0.788, min_ms: 0.404, max_ms: 0.86 }其中decoded_cells是判断解码成本的关键指标scan_all 为 40,000。仓库中已保存一份完整原始数据iotdb-2.0.8-macos-arm64.json。参考实测结果macOS arm64仓库自带的 results/README.md 汇总了一次真实运行结果环境为Apple M2 PromacOS arm64、Java 21.0.7、Go 1.26.5、IoTDB 2.0.8 standalone、双方客户端均锁定 2.0.8、10,000 行 Tree 数据、fetch size 1,024、15 次交替冷启动、5 次 RSS 采样、5 轮交替工作负载。指标JDBCGoGo 相对下降冷启动进程 建连p50172.612 ms9.315 ms94.6%常驻 RSS p5062,368 KB7,008 KB88.8%产物体积25,864,492 B6,475,202 B75.0%进程内建连均值66.061 ms1.932 ms97.1%SHOW DATABASES均值0.775 ms0.428 ms44.8%单点查询均值0.813 ms0.595 ms26.8%100 行查询均值1.437 ms1.010 ms29.7%10,000 行全量解码均值5.455 ms4.941 ms9.4%如何解读这份数据数据呈现出一个清晰的分层结论优势最大的维度是冷启动、内存与产物体积。Go 客户端冷启动快 94.6%JVM 启动开销消失常驻内存不到 JDBC 的八分之一62 MB → 7 MB单一二进制产物仅 6.5 MB。这三个维度直接决定了 Agent 进程的拉起速度、资源占用和分发成本——这正是 dbx 将生产 IoTDB Agent 迁移到 Go 的主要动因。建连延迟差距同样显著进程内建连从约 66 ms 降到约 1.9 ms。需要区分的是冷启动指标已包含进程拉起而connect_ms是连接建立本身的开销两者都被 Go 大幅改善。热查询差距相对温和且随工作负载加重而收窄元数据查询快 44.8%点查询快 26.8%100 行查询快 29.7%而全量扫描解码 40,000 个单元格时仅快 9.4%。这符合预期——服务端处理与结果解码的工作量越大客户端语言差异在总耗时中的占比就越小。结论方向该结果支持以 Go Agent 换取启动、建连、内存与分发体积上的收益热查询差异小到不足以成为迁移的阻碍。但正如 results/README.md 明确声明的此基准不包含dbx JSON-RPC Agent 层也不能证明功能与版本兼容性的完全对齐——那些需要依赖生产 Agent 的功能测试来保证。生产 Agent 的迁移现状源码侧佐证当前 agents/drivers/iotdb/README.md 明确说明该模块以官方 Apache IoTDB Go 客户端实现 DBX Agent 协议默认使用 Tree SQL可通过sql_dialecttable切换 Table 模型。其连接参数fetch_size、time_zone、connect_retry_max、ssl、node_urls等与基准测试中的部分配置一脉相承。值得注意的实现细节仓库将上游 Go 客户端 vendored 在 agents/go-common/iotdb-client-go 下并打了一个补丁——上游丢弃了 1.3.x 服务器的ColumnNameIndexMap回退逻辑会导致聚合结果与 SELECT 列顺序错位补丁后的客户端在缺少有序索引列表时通过服务器提供的名称索引映射值列。这说明基准测试只是决策链的一环真正的兼容性保障来自 integration_test.go 等测试可通过DBX_IOTDB_LIVE1 go test -race ./... -count1针对真实服务器运行。局限性与复现注意事项复现或引用这套基准时请留意以下边界单机单配置仓库仅保存了 macOS arm64 一组结果换到 Linux x86_64、不同 JDK/Go 版本或不同磁盘/网络环境下绝对数值必然变化相对趋势也未必完全一致客户端对比非服务器压测不要用这些数值推断 IoTDB 服务器容量不含 Agent 协议层结果不能直接代表 dbx 生产 Agent 端到端性能fetch size 一致性对比双方时务必保持相同 fetch size 与 fixture否则结论无效顺序效应默认BENCH_ORDERjdbc,go建议用BENCH_ORDERgo,jdbc复跑一轮以确认无顺序偏差。相关资源索引基准文档agents/drivers/iotdb/bench/README.md调度器实现agents/drivers/iotdb/bench/run.pyJDBC 基准实现agents/drivers/iotdb/bench/java/com/dbx/agent/iotdb/bench/JdbcDriverBenchmark.javaGo 基准实现agents/drivers/iotdb/bench/go/main.goGo 依赖声明agents/drivers/iotdb/bench/go/go.mod结果汇总agents/drivers/iotdb/bench/results/README.md原始数据agents/drivers/iotdb/bench/results/iotdb-2.0.8-macos-arm64.json生产 IoTDB Agent 说明agents/drivers/iotdb/README.md【免费下载链接】dbx20 MB lightweight cross-platform database client for 90 databases, including MySQL, PostgreSQL, SQLite, Redis, MongoDB, DuckDB, SQL Server, and Dameng. Built-in AI, MCP Server, CLI, desktop and Docker. | 轻量级跨平台数据库管理工具支持 MySQL、PostgreSQL、SQLite、Redis、MongoDB、达梦等 90 数据库提供桌面端、Docker、CLI、内置 AI 助手和 MCP Server。项目地址: https://gitcode.com/gh_mirrors/dbx7/dbx创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考