尧图网站建设 
GreptimeDB v0.12.0 TSBS 基准测试解析环境、复现方法与性能结果【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb本文基于 docs/benchmarks/tsbs/v0.12.0.md 结果文档结合同目录的 TSBS 运行指南 与仓库源码系统解读 GreptimeDB v0.12.0 在 Time Series Benchmark SuiteTSBS下的测试环境、完整复现流程、写入与查询性能数据并附上与历史版本结果文档的横向对比。读者可以据此理解 TSBS 基准的方法论、在自己的环境上复现该测试并读懂结果表格背后的含义。TSBS 基准测试与 GreptimeDBTSBSTime Series Benchmark Suite是业界广泛使用的时序数据库基准测试套件通过统一的devops用例模拟 DevOps 监控场景下的 CPU 指标采集对时序数据库的写入吞吐与查询延迟进行标准化度量。GreptimeDB 是开源可观测性数据库采用单列式存储引擎统一处理指标metrics、日志logs与链路追踪traces数据支持对象存储。仓库 docs/benchmarks/tsbs 目录下按版本归档了多轮 TSBS 结果文档v0.7.0、v0.8.0、v0.9.1、v0.12.0 等其中 v0.12.0.md 是本篇解读的主体它记录了 GreptimeDB v0.12.0 在 Amazon EC2 上的写入与 15 类查询性能数据。需要说明的是该轮测试仅公布了 EC2 环境数据早期版本如 v0.9.1 还包含本地机器数据因此本文对比时以 EC2 数据为主。测试环境v0.12.0 轮次的基准测试运行在单台 Amazon EC2 实例上实例规格如下项目配置机型c5d.2xlargeCPU8 核内存16GB磁盘100GBGP3操作系统Ubuntu Server 24.04 LTSc5d.2xlarge 是 AWS 计算优化型实例配备本地 NVMe SSDc5d 系列特性适合作为中规模时序工作负载的基准机。相比 v0.9.1/v0.8.0/v0.7.0 轮次v0.12.0 的磁盘从 50GB GP3 提升到 100GB GP3操作系统从 Ubuntu 22.04 升级为 Ubuntu Server 24.04 LTSv0.9.1 与 v0.12.0 的磁盘、OS 规格一致两者之间的数据对比最具参考价值详见下文对比章节。复现方法从生成数据到跑出结果的完整链路v0.12.0 结果文档本身只给出结论复现步骤完整记载在同目录的 TSBS 运行指南 中。以下步骤即官方推荐的完整复现流程。前置条件运行 TSBS 需要以下工具Go编译 TSBS 套件gitmakerust可选如果需要从源码构建 GreptimeDB构建 TSBS 套件TSBS 使用 GreptimeTeam 维护的 fork 版本内置了 GreptimeDB 专用的加载器与查询格式。克隆该 fork 后执行make编译git clone GreptimeTeam/tsbs fork 仓库 cd tsbs make编译完成后产物位于bin/目录可通过ls ./bin/查看。本文流程会用到其中 4 个二进制tsbs_generate_data生成测试数据tsbs_generate_queries生成查询集tsbs_load_greptimeGreptimeDB 专用数据加载器用于写入性能测试tsbs_run_queries_influx通过 InfluxDB 兼容协议执行查询用于查询性能测试生成测试数据使用tsbs_generate_data生成 3 天、4000 条时序、10 秒采样间隔的 CPU 监控数据mkdir bench-data ./bin/tsbs_generate_data --use-casecpu-only --seed123 --scale4000 \ --timestamp-start2023-06-11T00:00:00Z \ --timestamp-end2023-06-14T00:00:00Z \ --log-interval10s --formatinflux \ ./bench-data/influx-data.lp关键参数含义--use-casecpu-only使用 CPU 指标用例数据规模与 devops 用例一致但只包含 CPU 相关指标--seed123随机种子保证数据可复现--scale4000生成 4000 条独立时序对应 4000 台主机规模--timestamp-start/--timestamp-end数据时间范围共 3 天--log-interval10s采样间隔 10 秒即每条时序每天 8640 个数据点--formatinflux输出 InfluxDB 行协议Line Protocol格式因为后续写入走的是 GreptimeDB 的 InfluxDB 兼容写入接口生成查询集查询集由tsbs_generate_queries生成参数需与数据生成保持一致的--seed、--scale与时间范围。官方按 v0.12.0 结果表逐项生成了 15 个查询文件每组查询数量见下表./bin/tsbs_generate_queries \ --use-casedevops --seed123 --scale4000 \ --timestamp-start2023-06-11T00:00:00Z \ --timestamp-end2023-06-14T00:00:01Z \ --queries100 \ --query-type cpu-max-all-1 \ --formatgreptime \ ./bench-data/greptime-queries-cpu-max-all-1.dat注意两个与数据生成不同的地方--use-casedevops查询面向完整的 devops 用例--formatgreptime查询输出为 Greptime 兼容格式--timestamp-end比数据多 1 秒2023-06-14T00:00:01Z保证边界查询覆盖完整数据范围其余 14 个查询类型按同样方式逐个生成官方脚本使用的--queries数量与--query-type对应关系如下查询类型生成数量cpu-max-all-1 / cpu-max-all-8100double-groupby-1 / double-groupby-5 / double-groupby-all50groupby-orderby-limit50high-cpu-1 / high-cpu-all100 / 50lastpoint10single-groupby-1-1-1 / single-groupby-1-1-12 / single-groupby-1-8-1100single-groupby-5-1-1 / single-groupby-5-1-12 / single-groupby-5-8-1100所有生成命令的完整清单见 TSBS 运行指南第 57-178 行此处不再逐一罗列只需保持 seed、scale、时间范围一致即可。启动 GreptimeDB启动 GreptimeDB 前可参考仓库中的示例配置准备运行环境单机模式参考 config/standalone.example.toml分布式模式参考 config/datanode.example.toml、config/frontend.example.toml、config/metasrv.example.toml从源码构建 GreptimeDB 的方法可参考仓库 CONTRIBUTING.md。基准测试中写入与查询均通过http://localhost:4000访问对应示例配置中 http 服务的默认监听地址addr 127.0.0.1:4000。写入数据数据库启动后使用tsbs_load_greptime执行写入性能测试./bin/tsbs_load_greptime \ --urlshttp://localhost:4000 \ --file./bench-data/influx-data.lp \ --batch-size3000 \ --gzipfalse \ --workers6参数说明--urlsGreptimeDB 的 HTTP 写入端点--file上一步生成的行协议数据文件--batch-size3000每个批次的行数--gzipfalse是否压缩传输本例关闭--workers6并发写入线程数官方注明这些参数仅为示例可结合实际场景调整。写入侧的原理在 GreptimeDB 内部对应 HTTP/InfluxDB 兼容协议的数据接入层行协议数据经解析后进入列式存储引擎相关实现位于 src/servers 与 src/ingester 等模块。复现关键注意事项若要重复执行tsbs_load_greptime写入必须先销毁并重启数据库、清理历史数据重复数据会同时干扰写入与查询性能。运行查询数据导入完成后用tsbs_run_queries_influx逐个执行查询集./bin/tsbs_run_queries_influx --file./bench-data/greptime-queries-cpu-max-all-1.dat \ --db-namebenchmark \ --urlshttp://localhost:4000对 15 个查询文件分别执行相同命令文件名替换为对应.dat文件即可复现完整查询测试。查询侧走的是 InfluxDB 兼容查询接口tsbs_run_queries_influx由此得名GreptimeDB 将其解析为 SQL 后由查询引擎执行。重复查询无需重新导入数据直接再次执行相应命令即可。写入性能结果在 EC2 c5d.2xlarge 环境下v0.12.0 的写入速率为环境写入速率rows/sEC2 c5d.2xlarge326839.28横向对比同一目录下各版本文档在EC2 c5d.2xlarge上的写入速率注意 v0.7.0/v0.8.0 的磁盘为 50GB GP3、OS 为 Ubuntu 22.04与 v0.12.0 环境存在差异v0.9.1 与 v0.12.0 环境一致版本写入速率rows/sv0.7.0文档298716.66v0.8.0文档222148.56v0.9.1文档234620.19v0.12.0文档326839.28在环境完全一致的 v0.9.1 → v0.12.0 对比中写入吞吐从约 23.5 万行/秒提升至约 32.7 万行/秒。由于不同版本之间的磁盘与操作系统配置并非完全一致v0.7.0/v0.8.0跨版本数字的细微差异不宜过度解读但整体趋势与写入链路优化方向相符。查询性能结果15 类查询延迟EC2 c5d.2xlarge查询类型延迟mscpu-max-all-112.46cpu-max-all-824.20double-groupby-1673.08double-groupby-5963.99double-groupby-all1330.05groupby-orderby-limit952.46high-cpu-15.08high-cpu-all4638.57lastpoint591.02single-groupby-1-1-14.06single-groupby-1-1-124.73single-groupby-1-8-18.23single-groupby-5-1-14.61single-groupby-5-1-125.61single-groupby-5-8-19.74查询类型语义解读这批查询是 TSBS devops 用例的标准查询集可从命名推断其负载特征single-groupby-1-1-1 / -1-1-12 / -1-8-1 / -5-1-1 / -5-1-12 / -5-8-1命名格式为single-groupby-指标数-主机数-小时数即对指定数量的指标、主机做小时级聚合如均值/最大值。这类查询最轻量延迟普遍在 10ms 以内其中single-groupby-1-1-1仅 4.06ms是全表最快查询。cpu-max-all-1 / cpu-max-all-8查询 1 台 / 8 台主机在所有时间戳上的 CPU 最大值属于中等扫描 聚合负载延迟 12.46ms / 24.20ms。double-groupby-1 / -5 / -all双重重聚合先按主机、再按时间桶聚合扫描范围随主机数增大延迟从 673ms 递增到 1330ms。groupby-orderby-limit分组、排序并取 limit延迟 952.46ms验证排序路径。high-cpu-1 / high-cpu-all筛选 CPU 使用率高于阈值的主机high-cpu-all需扫描全部数据并做谓词判断是全表最重查询4638.57ms。lastpoint返回每台主机的最后一个数据点延迟 591.02ms。与历史版本的查询对比EC2 c5d.2xlarge单位 ms查询类型v0.7.0v0.8.0v0.9.1v0.12.0cpu-max-all-154.7415.2914.7512.46cpu-max-all-870.5033.5330.6924.20double-groupby-11366.631295.38987.85673.08double-groupby-52141.711993.911455.95963.99double-groupby-all3389.593056.772143.961330.05groupby-orderby-limit1213.901546.491353.49952.46high-cpu-152.9811.588.245.08high-cpu-all7194.918011.435312.824638.57lastpoint9423.419312.67576.06591.02single-groupby-1-1-17.777.676.014.06single-groupby-1-1-1251.649.297.424.73single-groupby-1-8-111.6417.9710.208.23single-groupby-5-1-19.6710.096.704.61single-groupby-5-1-1253.6212.378.725.61single-groupby-5-8-114.9623.1312.079.74v0.7.0/v0.8.0 数据来自 v0.7.0.md、v0.8.0.md其磁盘与 OS 环境与后两版不同v0.9.1 数据来自 v0.9.1.md与 v0.12.0 环境一致。从环境一致的 v0.9.1 → v0.12.0 看绝大多数查询延迟明显下降典型如double-groupby-1987.85ms → 673.08ms、high-cpu-all5312.82ms → 4638.57ms、groupby-orderby-limit1353.49ms → 952.46mslastpoint两项基本持平576.06ms → 591.02ms属于正常波动范围。更长期看与 v0.7.0/v0.8.0 相比lastpoint从约 9.4 秒量级大幅降至 0.6 秒量级high-cpu-all从约 8 秒降至 4.6 秒反映了存储与查询路径上持续的架构优化。此外v0.9.1 文档还额外给出了single-groupby-1-1-1在 50/100 并发下的吞吐QPS数据v0.12.0 文档未包含该项此处不再延伸。源码层面的佐证与解读版本标识机制v0.12.0 对应 GreptimeDB 的产品版本号版本信息通过 src/common/version/src/lib.rs 管理build_info()将编译期注入的GREPTIME_PRODUCT_VERSION与分支、commit、rustc、目标平台等构建元数据打包成BuildInfo可通过version()、verbose_version()、short_version()等接口输出。这意味着基准测试结果理论上可按构建元数据精确溯源到具体 commit。HTTP 写入/查询端口结果文档与运行指南中的http://localhost:4000对应 config/standalone.example.toml 中[http]段的默认addr 127.0.0.1:4000。TSBS 的写入加载器与查询客户端正是通过该 HTTP 端口以 InfluxDB 兼容协议与 GreptimeDB 通信相关协议解析与 gRPC/HTTP 服务入口位于 src/servers如 grpc.rs 中定义了 gRPC 的默认绑定地址。数据写入链路tsbs_load_greptime以行协议批量写入GreptimeDB 的 InfluxDB 接入层负责协议解析与行到列的转换随后进入存储引擎。这一链路对应的服务端实现可从 src/servers/src/influxdb若存在与存储层相关模块进一步追踪基准测试关注的核心指标——写入吞吐与查询延迟——最终都由引擎的列式存储、压缩与查询执行器决定。小结v0.12.0 轮次在 EC2 c5d.2xlarge8 核 / 16GB / 100GB GP3 / Ubuntu 24.04上测得写入速率326839.28 rows/s。15 类 TSBS 查询延迟从最快的single-groupby-1-1-14.06ms到最重的high-cpu-all4638.57ms覆盖了点查、范围聚合、多重重聚合、排序 limit、谓词过滤与 lastpoint 等典型时序负载形态。与环境一致的 v0.9.1 相比v0.12.0 在写入与绝大多数查询上均有明显改善更长期看自 v0.7.0 以来聚合与扫描类查询延迟持续下降。完整复现链路数据生成 → 查询生成 → 写入 → 查询详见 TSBS 运行指南所有命令均可直接复制执行复现时注意保持 seed、scale 与时间范围一致并避免在已有数据的库上重复写入。若需在本地或自有集群复测建议采用与官方一致的数据规模4000 条时序、10s 间隔、3 天与查询参数并记录机器的 CPU/内存/磁盘/OS 规格以保证结果可对比、可追溯。【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 GreptimeDB v0.12.0 TSBS 基准测试解析：环境、复现方法与性能结果
GreptimeDB v0.12.0 TSBS 基准测试解析环境、复现方法与性能结果【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb本文基于 docs/benchmarks/tsbs/v0.12.0.md 结果文档结合同目录的 TSBS 运行指南 与仓库源码系统解读 GreptimeDB v0.12.0 在 Time Series Benchmark SuiteTSBS下的测试环境、完整复现流程、写入与查询性能数据并附上与历史版本结果文档的横向对比。读者可以据此理解 TSBS 基准的方法论、在自己的环境上复现该测试并读懂结果表格背后的含义。TSBS 基准测试与 GreptimeDBTSBSTime Series Benchmark Suite是业界广泛使用的时序数据库基准测试套件通过统一的devops用例模拟 DevOps 监控场景下的 CPU 指标采集对时序数据库的写入吞吐与查询延迟进行标准化度量。GreptimeDB 是开源可观测性数据库采用单列式存储引擎统一处理指标metrics、日志logs与链路追踪traces数据支持对象存储。仓库 docs/benchmarks/tsbs 目录下按版本归档了多轮 TSBS 结果文档v0.7.0、v0.8.0、v0.9.1、v0.12.0 等其中 v0.12.0.md 是本篇解读的主体它记录了 GreptimeDB v0.12.0 在 Amazon EC2 上的写入与 15 类查询性能数据。需要说明的是该轮测试仅公布了 EC2 环境数据早期版本如 v0.9.1 还包含本地机器数据因此本文对比时以 EC2 数据为主。测试环境v0.12.0 轮次的基准测试运行在单台 Amazon EC2 实例上实例规格如下项目配置机型c5d.2xlargeCPU8 核内存16GB磁盘100GBGP3操作系统Ubuntu Server 24.04 LTSc5d.2xlarge 是 AWS 计算优化型实例配备本地 NVMe SSDc5d 系列特性适合作为中规模时序工作负载的基准机。相比 v0.9.1/v0.8.0/v0.7.0 轮次v0.12.0 的磁盘从 50GB GP3 提升到 100GB GP3操作系统从 Ubuntu 22.04 升级为 Ubuntu Server 24.04 LTSv0.9.1 与 v0.12.0 的磁盘、OS 规格一致两者之间的数据对比最具参考价值详见下文对比章节。复现方法从生成数据到跑出结果的完整链路v0.12.0 结果文档本身只给出结论复现步骤完整记载在同目录的 TSBS 运行指南 中。以下步骤即官方推荐的完整复现流程。前置条件运行 TSBS 需要以下工具Go编译 TSBS 套件gitmakerust可选如果需要从源码构建 GreptimeDB构建 TSBS 套件TSBS 使用 GreptimeTeam 维护的 fork 版本内置了 GreptimeDB 专用的加载器与查询格式。克隆该 fork 后执行make编译git clone GreptimeTeam/tsbs fork 仓库 cd tsbs make编译完成后产物位于bin/目录可通过ls ./bin/查看。本文流程会用到其中 4 个二进制tsbs_generate_data生成测试数据tsbs_generate_queries生成查询集tsbs_load_greptimeGreptimeDB 专用数据加载器用于写入性能测试tsbs_run_queries_influx通过 InfluxDB 兼容协议执行查询用于查询性能测试生成测试数据使用tsbs_generate_data生成 3 天、4000 条时序、10 秒采样间隔的 CPU 监控数据mkdir bench-data ./bin/tsbs_generate_data --use-casecpu-only --seed123 --scale4000 \ --timestamp-start2023-06-11T00:00:00Z \ --timestamp-end2023-06-14T00:00:00Z \ --log-interval10s --formatinflux \ ./bench-data/influx-data.lp关键参数含义--use-casecpu-only使用 CPU 指标用例数据规模与 devops 用例一致但只包含 CPU 相关指标--seed123随机种子保证数据可复现--scale4000生成 4000 条独立时序对应 4000 台主机规模--timestamp-start/--timestamp-end数据时间范围共 3 天--log-interval10s采样间隔 10 秒即每条时序每天 8640 个数据点--formatinflux输出 InfluxDB 行协议Line Protocol格式因为后续写入走的是 GreptimeDB 的 InfluxDB 兼容写入接口生成查询集查询集由tsbs_generate_queries生成参数需与数据生成保持一致的--seed、--scale与时间范围。官方按 v0.12.0 结果表逐项生成了 15 个查询文件每组查询数量见下表./bin/tsbs_generate_queries \ --use-casedevops --seed123 --scale4000 \ --timestamp-start2023-06-11T00:00:00Z \ --timestamp-end2023-06-14T00:00:01Z \ --queries100 \ --query-type cpu-max-all-1 \ --formatgreptime \ ./bench-data/greptime-queries-cpu-max-all-1.dat注意两个与数据生成不同的地方--use-casedevops查询面向完整的 devops 用例--formatgreptime查询输出为 Greptime 兼容格式--timestamp-end比数据多 1 秒2023-06-14T00:00:01Z保证边界查询覆盖完整数据范围其余 14 个查询类型按同样方式逐个生成官方脚本使用的--queries数量与--query-type对应关系如下查询类型生成数量cpu-max-all-1 / cpu-max-all-8100double-groupby-1 / double-groupby-5 / double-groupby-all50groupby-orderby-limit50high-cpu-1 / high-cpu-all100 / 50lastpoint10single-groupby-1-1-1 / single-groupby-1-1-12 / single-groupby-1-8-1100single-groupby-5-1-1 / single-groupby-5-1-12 / single-groupby-5-8-1100所有生成命令的完整清单见 TSBS 运行指南第 57-178 行此处不再逐一罗列只需保持 seed、scale、时间范围一致即可。启动 GreptimeDB启动 GreptimeDB 前可参考仓库中的示例配置准备运行环境单机模式参考 config/standalone.example.toml分布式模式参考 config/datanode.example.toml、config/frontend.example.toml、config/metasrv.example.toml从源码构建 GreptimeDB 的方法可参考仓库 CONTRIBUTING.md。基准测试中写入与查询均通过http://localhost:4000访问对应示例配置中 http 服务的默认监听地址addr 127.0.0.1:4000。写入数据数据库启动后使用tsbs_load_greptime执行写入性能测试./bin/tsbs_load_greptime \ --urlshttp://localhost:4000 \ --file./bench-data/influx-data.lp \ --batch-size3000 \ --gzipfalse \ --workers6参数说明--urlsGreptimeDB 的 HTTP 写入端点--file上一步生成的行协议数据文件--batch-size3000每个批次的行数--gzipfalse是否压缩传输本例关闭--workers6并发写入线程数官方注明这些参数仅为示例可结合实际场景调整。写入侧的原理在 GreptimeDB 内部对应 HTTP/InfluxDB 兼容协议的数据接入层行协议数据经解析后进入列式存储引擎相关实现位于 src/servers 与 src/ingester 等模块。复现关键注意事项若要重复执行tsbs_load_greptime写入必须先销毁并重启数据库、清理历史数据重复数据会同时干扰写入与查询性能。运行查询数据导入完成后用tsbs_run_queries_influx逐个执行查询集./bin/tsbs_run_queries_influx --file./bench-data/greptime-queries-cpu-max-all-1.dat \ --db-namebenchmark \ --urlshttp://localhost:4000对 15 个查询文件分别执行相同命令文件名替换为对应.dat文件即可复现完整查询测试。查询侧走的是 InfluxDB 兼容查询接口tsbs_run_queries_influx由此得名GreptimeDB 将其解析为 SQL 后由查询引擎执行。重复查询无需重新导入数据直接再次执行相应命令即可。写入性能结果在 EC2 c5d.2xlarge 环境下v0.12.0 的写入速率为环境写入速率rows/sEC2 c5d.2xlarge326839.28横向对比同一目录下各版本文档在EC2 c5d.2xlarge上的写入速率注意 v0.7.0/v0.8.0 的磁盘为 50GB GP3、OS 为 Ubuntu 22.04与 v0.12.0 环境存在差异v0.9.1 与 v0.12.0 环境一致版本写入速率rows/sv0.7.0文档298716.66v0.8.0文档222148.56v0.9.1文档234620.19v0.12.0文档326839.28在环境完全一致的 v0.9.1 → v0.12.0 对比中写入吞吐从约 23.5 万行/秒提升至约 32.7 万行/秒。由于不同版本之间的磁盘与操作系统配置并非完全一致v0.7.0/v0.8.0跨版本数字的细微差异不宜过度解读但整体趋势与写入链路优化方向相符。查询性能结果15 类查询延迟EC2 c5d.2xlarge查询类型延迟mscpu-max-all-112.46cpu-max-all-824.20double-groupby-1673.08double-groupby-5963.99double-groupby-all1330.05groupby-orderby-limit952.46high-cpu-15.08high-cpu-all4638.57lastpoint591.02single-groupby-1-1-14.06single-groupby-1-1-124.73single-groupby-1-8-18.23single-groupby-5-1-14.61single-groupby-5-1-125.61single-groupby-5-8-19.74查询类型语义解读这批查询是 TSBS devops 用例的标准查询集可从命名推断其负载特征single-groupby-1-1-1 / -1-1-12 / -1-8-1 / -5-1-1 / -5-1-12 / -5-8-1命名格式为single-groupby-指标数-主机数-小时数即对指定数量的指标、主机做小时级聚合如均值/最大值。这类查询最轻量延迟普遍在 10ms 以内其中single-groupby-1-1-1仅 4.06ms是全表最快查询。cpu-max-all-1 / cpu-max-all-8查询 1 台 / 8 台主机在所有时间戳上的 CPU 最大值属于中等扫描 聚合负载延迟 12.46ms / 24.20ms。double-groupby-1 / -5 / -all双重重聚合先按主机、再按时间桶聚合扫描范围随主机数增大延迟从 673ms 递增到 1330ms。groupby-orderby-limit分组、排序并取 limit延迟 952.46ms验证排序路径。high-cpu-1 / high-cpu-all筛选 CPU 使用率高于阈值的主机high-cpu-all需扫描全部数据并做谓词判断是全表最重查询4638.57ms。lastpoint返回每台主机的最后一个数据点延迟 591.02ms。与历史版本的查询对比EC2 c5d.2xlarge单位 ms查询类型v0.7.0v0.8.0v0.9.1v0.12.0cpu-max-all-154.7415.2914.7512.46cpu-max-all-870.5033.5330.6924.20double-groupby-11366.631295.38987.85673.08double-groupby-52141.711993.911455.95963.99double-groupby-all3389.593056.772143.961330.05groupby-orderby-limit1213.901546.491353.49952.46high-cpu-152.9811.588.245.08high-cpu-all7194.918011.435312.824638.57lastpoint9423.419312.67576.06591.02single-groupby-1-1-17.777.676.014.06single-groupby-1-1-1251.649.297.424.73single-groupby-1-8-111.6417.9710.208.23single-groupby-5-1-19.6710.096.704.61single-groupby-5-1-1253.6212.378.725.61single-groupby-5-8-114.9623.1312.079.74v0.7.0/v0.8.0 数据来自 v0.7.0.md、v0.8.0.md其磁盘与 OS 环境与后两版不同v0.9.1 数据来自 v0.9.1.md与 v0.12.0 环境一致。从环境一致的 v0.9.1 → v0.12.0 看绝大多数查询延迟明显下降典型如double-groupby-1987.85ms → 673.08ms、high-cpu-all5312.82ms → 4638.57ms、groupby-orderby-limit1353.49ms → 952.46mslastpoint两项基本持平576.06ms → 591.02ms属于正常波动范围。更长期看与 v0.7.0/v0.8.0 相比lastpoint从约 9.4 秒量级大幅降至 0.6 秒量级high-cpu-all从约 8 秒降至 4.6 秒反映了存储与查询路径上持续的架构优化。此外v0.9.1 文档还额外给出了single-groupby-1-1-1在 50/100 并发下的吞吐QPS数据v0.12.0 文档未包含该项此处不再延伸。源码层面的佐证与解读版本标识机制v0.12.0 对应 GreptimeDB 的产品版本号版本信息通过 src/common/version/src/lib.rs 管理build_info()将编译期注入的GREPTIME_PRODUCT_VERSION与分支、commit、rustc、目标平台等构建元数据打包成BuildInfo可通过version()、verbose_version()、short_version()等接口输出。这意味着基准测试结果理论上可按构建元数据精确溯源到具体 commit。HTTP 写入/查询端口结果文档与运行指南中的http://localhost:4000对应 config/standalone.example.toml 中[http]段的默认addr 127.0.0.1:4000。TSBS 的写入加载器与查询客户端正是通过该 HTTP 端口以 InfluxDB 兼容协议与 GreptimeDB 通信相关协议解析与 gRPC/HTTP 服务入口位于 src/servers如 grpc.rs 中定义了 gRPC 的默认绑定地址。数据写入链路tsbs_load_greptime以行协议批量写入GreptimeDB 的 InfluxDB 接入层负责协议解析与行到列的转换随后进入存储引擎。这一链路对应的服务端实现可从 src/servers/src/influxdb若存在与存储层相关模块进一步追踪基准测试关注的核心指标——写入吞吐与查询延迟——最终都由引擎的列式存储、压缩与查询执行器决定。小结v0.12.0 轮次在 EC2 c5d.2xlarge8 核 / 16GB / 100GB GP3 / Ubuntu 24.04上测得写入速率326839.28 rows/s。15 类 TSBS 查询延迟从最快的single-groupby-1-1-14.06ms到最重的high-cpu-all4638.57ms覆盖了点查、范围聚合、多重重聚合、排序 limit、谓词过滤与 lastpoint 等典型时序负载形态。与环境一致的 v0.9.1 相比v0.12.0 在写入与绝大多数查询上均有明显改善更长期看自 v0.7.0 以来聚合与扫描类查询延迟持续下降。完整复现链路数据生成 → 查询生成 → 写入 → 查询详见 TSBS 运行指南所有命令均可直接复制执行复现时注意保持 seed、scale 与时间范围一致并避免在已有数据的库上重复写入。若需在本地或自有集群复测建议采用与官方一致的数据规模4000 条时序、10s 间隔、3 天与查询参数并记录机器的 CPU/内存/磁盘/OS 规格以保证结果可对比、可追溯。【免费下载链接】greptimedbThe open-source observability database. One columnar engine for metrics, logs, and traces, on object storage.项目地址: https://gitcode.com/GitHub_Trending/gr/greptimedb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考