Benchmarks
针对分析场景下的数据，IEDB 具备业界领先的性能表现。本页面记录了相关的基准测试方法及测试结果。
总结
| 指标 | 结果 |
|---|---|
| 写入 (MessagePack) | 每秒超过 1800 万条记录 |
| 查询 (Arrow) | 每秒 600 万行以上 |
| 查询 (JSON) | 223万行/秒 |
| Line Protocol | 192万条记录/秒 |
硬件
基准测试基于苹果 MacBook Pro M3 Max（14 核心，48GB 内存，1TB NVMe）。
测试配置：12 个并发工作进程，1000 条记录批次，IoT 传感器数据。
数据写入
| 协议 | 吞吐量 | p50延迟 | p99延迟 |
|---|---|---|---|
| MessagePack 列式 | 1860万条记录/秒 | 0.46毫秒 | 3.68毫秒 |
| MessagePack + Zstd | 1680万条记录/秒 | 0.55毫秒 | 3.23毫秒 |
| MessagePack + GZIP | 1540万条记录/秒 | 0.63毫秒 | 3.17毫秒 |
| Line Protocol | 370万条记录/秒 | 2.63毫秒 | 10.63毫秒 |
文件压缩
自动后台压缩将小的 Parquet 文件合并为优化的大文件：
| 指标 | 压缩前 | 压缩后 | 减少率 |
|---|---|---|---|
| 文件数量 | 43 | 1 | 97.7% |
| 大小 | 372 MB | 36 MB | 90.4% |
优势：
- 10倍存储减少 通过更好的压缩和编码
- 更快查询 - 扫描1个文件而非43个文件
- 更低云成本 - 更少存储，更少API调用
查询（2026年1月）
对于大型结果集，Arrow IPC 格式比 JSON 提供 2 倍吞吐量：
| 查询 | Arrow (毫秒) | JSON (毫秒) | 加速比 |
|---|---|---|---|
| COUNT(*) - 全表 | 6.7 | 9.0 | 1.35x |
| SELECT LIMIT 10K | 27 | 31 | 1.14x |
| SELECT LIMIT 100K | 55 | 103 | 1.88x |
| SELECT LIMIT 500K | 201 | 420 | 2.10x |
| SELECT LIMIT 1M | 379 | 789 | 2.08x |
| AVG/MIN/MAX 聚合 | 146 | 146 | 1.00x |
| GROUP BY host (Top 10) | 107 | 104 | 0.98x |
| INTERVAL '1 hour' | 12 | 11 | 0.96x |
最佳吞吐量：
- Arrow: 264万行/秒 (100万行SELECT)
- JSON: 127万行/秒 (100万行SELECT)
- COUNT(*): 120-1900亿行/秒 (1.34亿行，7-11毫秒)
ClickBench 测试结果
在命中数据集上进行行业标准分析查询基准测试。
测试环境：
- 实例：云服务器（16 个虚拟 CPU，32GB 内存）
- 数据集：1亿行（14GB Parquet格式）
- 查询：43 个分析查询
| 运行 | Total Time | 查询数量 |
|---|---|---|
| 冷启动 (cache flushed) | 120.25s | 43 |
| 热启动 | 35.70s | 43 |
产品对比
| 数据库 | 热启动 | 相对速度 |
|---|---|---|
| IEDB | 35.70秒 | 1.00倍（基线） |
| QuestDB | 64.26秒 | 速度慢 1.80 倍 |
| TimescaleDB | 335.22秒 | 速度慢 9.39 倍 |
在分析工作负载方面， IEDB 的速度比 QuestDB 快 1.80 倍，比 TimescaleDB 快 9.39 倍。
为什么IEDB速度快
1. 查询引擎
利用了 DuckDB 的列式执行引擎：
- 向量化执行：每条 CPU 指令处理数千个值
- 并行查询执行：自动利用所有 CPU 核心
- 高级优化：连接重排序、谓词下推、过滤器下推
- SIMD 指令：使用现代 CPU 特性
2. 列式文件存储
- 列式格式：查询所需的只读列
- 压缩后的数据量比原始数据小 80%（Snappy/ZSTD）
- 谓词下推：根据统计信息跳过整个行组
- 高效扫描：查询引擎原生支持读取 Parquet 格式
3. Go 运行时效率
- 内存稳定：Go的垃圾回收器将内存归还给操作系统。无泄漏。
- 单一二进制文件：部署单个可执行文件。无依赖项。
- 原生并发：Goroutines 高效处理数千个连接。
- 生产级垃圾回收：大规模下的亚毫秒级暂停时间。
性能建议
写入优化
- 使用 MessagePack 列格式
data = {"m": "cpu", "columns": {...}} # 18M+ rec/s
# vs
data = "cpu,host=x value=1" # 1.92M rec/s
- 批量写入（每次请求 10,000 条以上记录）
- 启用 gzip 压缩以提高网络效率
- 使用多线程（M3 Max 最佳使用 35 个）
查询优化
- 对于大型结果集（10000 行以上），请使用 Arrow 格式。
response = requests.post(url + "/api/v1/query/arrow", ...)
- 启用查询压缩以优化查询
[compaction]
enabled = true
- 使用聚合时间
WHERE time > now() - INTERVAL '1 hour'
扩展特性
服务器更换更强的 CPU（更多核心），系统的处理能力会几乎等比例提升（例如核心数翻倍，性能接近翻倍）。
- CPU：核心数量与扩展性呈近线性关系
- 内存：自动配置为系统内存的约 50%
存储影响
| 后端 | 写入开销 | 查询开销 |
|---|---|---|
| 本地 NVMe | 基线 | 基线 |
| MinIO（本地） | +5-10% | +2-5% |
| S3 | +20-30% | +10-20% |
自行测试
在本地运行基准测试：
cd iedb
make bench