39 lines
2.9 KiB
Markdown
39 lines
2.9 KiB
Markdown
# TimescaleDB 性能测试分析报告
|
||
|
||
基于 `test_db.py` 对 30 万条车辆仿真数据的写入与查询测试，本次性能评估结论如下：
|
||
|
||
## 1. 核心结论
|
||
|
||
**TimescaleDB 完全满足智能电动车数字孪生系统（SmartEDT）的实时采集与回放需求。**
|
||
|
||
- **写入能力**：单线程下 **3,500+ TPS** 的写入速度远超单车采集需求（通常单车高频信号仅需 50-100Hz，即 50-100 TPS）。即使并发接入 10-20 台车，当前配置也绰绰有余。
|
||
- **查询响应**：**毫秒级（30ms）** 的时间切片查询能力，保证了“前端实时回放”与“大屏曲线刷新”的流畅度，不会出现卡顿。
|
||
- **存储架构**：JSONB 混合存储方案在保持了极高灵活性的同时（0.2s 过滤查询），依然维持了优秀的查询性能，验证了“结构化字段（索引）+ 半结构化 Payload（JSONB）”建模方案的正确性。
|
||
|
||
## 2. 详细指标分析
|
||
|
||
### 2.1 写入性能 (Insertion)
|
||
* **指标**：3,547.78 条/秒 (TPS)
|
||
* **场景**：单连接、Batch=1000、Python `asyncpg` 驱动。
|
||
* **分析**：
|
||
* **满足度**：假设单车采集频率为 50Hz（即每秒 50 个数据包），当前性能理论上可支持 **70 台车同时在线采集**。
|
||
* **瓶颈推测**：当前瓶颈主要在 Python 端的序列化与网络 IO 往返（RTT）。
|
||
* **优化空间**：如果未来需要支持上千台车，改用 `COPY` 协议或增加并发写入 worker，吞吐量可轻松提升至 5-10 万 TPS 以上。
|
||
|
||
### 2.2 查询性能 (Query)
|
||
|
||
| 查询类型 | 耗时 | 业务场景 | 评价 |
|
||
| :--- | :--- | :--- | :--- |
|
||
| **最新数据 (Latest 1000)** | **0.0301s** | 实时大屏监控、轨迹回放 | **极优**。利用 TimescaleDB 的时间分区索引，无论历史数据多大，提取“最新 N 条”永远是毫秒级。 |
|
||
| **全量计数 (Count)** | 0.0845s | 报表统计、数据完整性校验 | **优秀**。30万数据秒出，说明元数据管理高效。 |
|
||
| **JSONB 内容过滤** | 0.2137s | 复杂故障诊断、特定工况筛选 | **良好**。在没有对 JSON 内部字段建索引的情况下，0.2s 扫描 30 万条 JSON 数据属于高性能表现。 |
|
||
|
||
## 3. 架构建议
|
||
|
||
基于测试结果，对后续开发提出以下建议：
|
||
|
||
1. **保持 JSONB 方案**：当前的表结构（`ts`, `simulation_id`, `signals(JSONB)`）在性能与灵活性之间取得了完美平衡，无需拆分更多列。
|
||
2. **索引优化**：目前 `ts` 和 `simulation_id` 已有索引。如果未来经常需要按“车速”或“故障码”过滤，建议对 JSONB 内部高频查询字段建立 **GIN 索引**。
|
||
* *示例 SQL*：`CREATE INDEX idx_speed ON vehicle_signals USING gin ((signals->'vehicle_speed_kmh'));`
|
||
3. **保留策略**：建议配置 TimescaleDB 的 `retention_policy`，例如自动删除 30 天前的原始高频数据，只保留降采样后的聚合数据，以节省磁盘空间。
|