随着智能汽车行业的迅猛发展，车载数据量激增，对数据的存储、查询和管理提出了更高要求。面对这些挑战，我们提出了车云一体的解决方案，以实现更高效的车端数据管理与应用。在车云一体方案 中，GreptimeDB Edge 是专为车机设计的数据库，它针对存储和计算进行了优化，以极低的资源消耗实现高效的数据处理。这使得车机端可以充分利用车内的算力来开发应用，满足数据采集和计算的需求。此外，GreptimeDB Edge 支持高压缩率的数据文件同步至云端对象存储，供云端查询使用，显著降低了带宽流量费用。

在资源受限的车载环境中，尽管芯片算力不断提升，但分配给基础服务的资源依然十分有限，所以性能尤为关键。本文将向大家展示 GreptimeDB Edge 在高写入负载下的性能数据 和 实际生产环境中的压缩率表现。

📅 Greptime 首个线上发布会来袭，点击预约。

测试环境

硬件平台

软件版本

Edge 关键配置

• 所有表都禁用 WAL（预写日志）。虽然 WAL 可以增强数据的可靠性，但其对磁盘 IO 的增加可能会加速磁盘磨损，从而缩短其使用寿命。对于重要的数据，我们可以开启 WAL 来增强数据可靠性。在性能测试中，为了优化 IO 性能，我们选择禁用 WAL。

• 写入时，数据先写入内存中，并在内存中累积，当数据量达到设定的阈值时，会将数据刷写到磁盘。在性能测试中，我们限制单个表的内存使用量为 1 MB，所有表的总的内存使用为 50 MB。

测试数据

• 30 张表，每张表 10 个字段。

• 字段类型有三种：int32, uint32, bool。

• 除了时间戳字段外，其余的字段均为 field，而非 tag。

写入方式

• 模拟一个写入程序，通过商用的 SDK（基于共享内存通信） 写入 GreptimeDB Edge。

• 写入程序可以根据配置产生相应的写入负载。

测试报告

每秒 35w 点写入

在每秒 35w 点 的写入负载下，我们采集了 GreptimeDB Edge 在 30 分钟内的性能数据。GreptimeDB Edge 的 CPU 使用率平均 单核 3%，峰值未超过 15%。在内存使用方面，GreptimeDB Edge 的常驻内存大小（Resident Memory Size）在 120 MB 至 166 MB 之间波动，平均为 132 MB。具体数据如下所示，供大家参考：

写入速率（约 35w 每秒）

CPU Usage 折线图

内存（Resident Memory Size）折线图

每秒 70w 点写入

在每秒 70w 点的写入负载下，我们采集了 GreptimeDB Edge 在 30 分钟内的性能数据。GreptimeDB Edge 的 CPU 使用率平均 单核 5.7%，峰值未超过 **15%。在内存使用方面，GreptimeDB Edge 的常驻内存大小（Resident Memory Size）在 130 MB 至 150 MB 之间波动，平均为 135 MB。具体数据如下所示，供大家参考：

写入负载

CPU Usage 折线图

内存（Resident Memory Size）折线图

压缩率

除了 CPU 和内存，压缩率也是一个非常重要的指标。高效的数据压缩能够显著减少网络流量和数据传输成本，另一方面，数据可以在本地存储更长的时间，换句话说，存储相同的数据可以节省磁盘空间。压缩率的高低与数据特征息息相关。GreptimeDB 车云方案已成功应用于某新能源车企，性能表现优异。在本节中，我们将展示 GreptimeDB Edge 在实车中的压缩率表现。

先简单介绍一下业务场景：

• 我们在车载信息娱乐系统（HU）中集成了一个完整的数据库 GreptimeDB Edge，以系统服务的形式运行。

• 企业自主开发的服务负责收集车辆的 CAN 信号。该服务利用基于共享内存通信的 SDK，将收集到的 CAN 信号高效地写入 GreptimeDB Edge 中。写入速率约为 25w 点每秒。

• 每 3 分钟进行一次数据导出，并且上传，导入云端的 GreptimeDB 集群。

• 其他

• 芯片：骁龙 8295

• 系统：Android 12

我们采集了 30 分钟左右的 GreptiemDB Edge 导出的数据。

• 总计导出 10 个文件，总大小 42 MB。

• 对应的 ASC 格式的文件大小为 1.3GB。

ASC log format 是 Vector 公司提供的一种用于记录和分析 CAN 总线数据的 ASCII 文本文件格式。具体可参阅：CAN_LOG_TRIGGER_ASC_Format.pdf。

综上：GreptimeDB Edge 相较于传统的 ASC 文件格式，实现了 30 至 40 倍的压缩率。与车企之前采用的方法相比，压缩率提高了一倍，有助于车企实现成本控制与效率提升。

GreptimeDB Edge 采用列式存储布局，并能够根据数据特性在列维度上选择最合适的编码和压缩算法。

值得注意的是，CPU、内存 和 压缩率之间存在一个典型的权衡关系。在实际应用中，我们需要根据不同的场景和需求进行一些参数调整。例如，为了提高压缩率，可能需要消耗更多 CPU 和内存资源。反之，如果目标是降低 CPU 的使用率，则可能会牺牲一些内存和压缩效率。

总结

测试结果表明

• GreptimeDB Edge 在面对高写入负载时拥有良好的性能。在 35w 点每秒 以及 70w 点每秒的写入负载下，GreptimeDB Edge 的 CPU 使用率均值分别为 单核 3% 和 5%，峰值均未超过 15%。常驻内存大小在 130MB 左右。CPU 使用率和内存占用非常平滑。这些都促使 GreptimeDB Edge 能够在不影响整体系统性能的前提下，高效地处理大量数据，从而成为一个可靠的车端数据中心解决方案。

• 在真实车企的场景下，我们探讨了 GreptimeDB Edge 针对 CAN 数据的压缩率，相较于 ASC 文件，实现了 30 至 40 倍的压缩率。与车企之前的方案相比，压缩率提高了一倍，助力企业降本增效。

未来，我们将持续优化 GreptimeDB Edge 的性能，为新能源和智能汽车产业的创新贡献更多技术支持。

更多 Greptime 相关测试报告详见 ：

• GreptimeDB vs. SQLite —— 高通 8155 平台上的性能对比报告
  

• 超完整性能报告合集｜GreptimeDB 多场景性能对比和深度解析来袭！
  

• GreptimeDB vs. ClickHouse vs. ElasticSearch 日志引擎性能对比报告
  

• GreptimeDB vs. InfluxDB 性能测试报告
  

• 单集群 100 节点！资源占用远小于 Grafana Mimir——GreptimeDB 海量数据写入性能报告
  

性能报告将不断迭代，欢迎大家持续关注。

✒️ GreptimeDB Edge 2.0 车端多模态数据库线上发布会来了！更多信息请看👇海报

关于 Greptime

Greptime 格睿科技专注于为可观测、物联网及车联网等领域提供实时、高效的数据存储和分析服务，帮助客户挖掘数据的深层价值。目前基于云原生的时序数据库 GreptimeDB 已经衍生出多款适合不同用户的解决方案，更多信息或 demo 展示请联系下方小助手（微信号：greptime）。

欢迎对开源感兴趣的朋友们参与贡献和讨论，从带有 good first issue 标签的 issue 开始你的开源之旅吧～期待在开源社群里遇见你！添加小助手微信即可加入“技术交流群”与志同道合的朋友们面对面交流哦~

Star us on GitHub Now: https://github.com/GreptimeTeam/greptimedb

官网：https://greptime.cn/

文档：https://docs.greptime.cn/

Twitter: https://twitter.com/Greptime

Slack: https://greptime.com/slack

LinkedIn: https://www.linkedin.com/company/greptime/