SonnetDB 支持多种数据摄入格式,每种格式在可读性、传输效率和解析性能上各有优劣。选择合适的写入格式对于系统性能和开发效率至关重要。本文将从多个维度对比 Line Protocol、JSON 和 SQL VALUES 三种主流格式。
JSON 格式是最直观的写入方式,数据结构清晰,适合与 Web 应用和 REST API 集成。
POST /api/v1/write
Content-Type: application/json
{
"measurement": "sensor_data",
"points": [
{
"time": 1713676800000,
"tags": {"device_id": "s01", "location": "factory-a"},
"fields": {"temperature": 23.5, "humidity": 65.2, "pressure": 1013.2}
}
]
}
优点:可读性最强,嵌套结构天然支持,与 JavaScript/TypeScript 生态无缝配合,是 Web 前端和 REST API 集成的首选。缺点:序列化和反序列化开销较大,数据传输体积最大(约比 Line Protocol 大 40-60%),在批量写入大量数据时带宽和 CPU 消耗明显。
Line Protocol 源自 InfluxDB,是一种紧凑的文本格式,每行代表一个数据点,语法为 measurement,tags fields timestamp。
POST /api/v1/ingest
Content-Type: text/plain
sensor_data,device_id=s01,location=factory-a temperature=23.5,humidity=65.2,pressure=1013.2 1713676800000
sensor_data,device_id=s02,location=factory-a temperature=24.1,humidity=63.8,pressure=1012.9 1713676800001
sensor_data,device_id=s03,location=factory-b temperature=22.8,humidity=66.1,pressure=1014.0 1713676800002
优点:文本体积紧凑(比 JSON 小约 50%),解析速度极快,InfluxDB 用户可零成本迁移,适合高吞吐量的 IoT 数据采集。缺点:不支持嵌套结构,所有值均为字符串表示(无类型标记),可读性不如 JSON。
SQL VALUES 是最标准的写入方式,使用 INSERT INTO ... VALUES 语句,适合在 SQL 客户端和脚本中使用。
INSERT INTO sensor_data (time, device_id, location, temperature, humidity, pressure)
VALUES (1713676800000, 's01', 'factory-a', 23.5, 65.2, 1013.2),
(1713676800001, 's02', 'factory-a', 24.1, 63.8, 1012.9),
(1713676800002, 's03', 'factory-b', 22.8, 66.1, 1014.0);
优点:SQL 标准语法,任何 SQL 工具都可直接使用,类型明确(字符串用引号、数字不用),在 REPL 和脚本中非常方便。缺点:解析路径最长(需经过完整的 SQL 解析器),批量性能相对最低,不适合超大批量写入。
以下是三种格式在同等条件下的实测性能对比(写入 10 万条数据点):
| 指标 | JSON | Line Protocol | SQL VALUES |
|---|---|---|---|
| 传输体积 | ~8.2 MB | ~4.5 MB | ~5.1 MB |
| 解析时间 | 185 ms | 92 ms | 210 ms |
| 总写入时间 | 320 ms | 230 ms | 380 ms |
| CPU 开销 | 高 | 低 | 中 |
| 可读性 | 优秀 | 良好 | 优秀 |
根据不同的使用场景,建议如下选择:
?flush=async 参数获取最佳吞吐量总结而言,SonnetDB 对三种格式的全面支持确保了不同场景下的灵活选择。Line Protocol 在性能上领先,JSON 在开发体验上占优,SQL VALUES 则在标准化方面无可替代。根据实际需求选择最合适的格式,能让您的系统在开发效率和运行性能之间达到最佳平衡。