使用场景

车联网是典型场景。在这样的场景下，存储和查询汽车物联网设备产生的大量位置数据是非常有必要的。

位置数据具有以下重要特征：

• 写入频率高：每天需要写入超过2亿条位置数据记录。
• 阅读频率低：追踪最近几天的位置数据是最常用的查询。
• 企业客户通常需要根据自己的使用场景自定义保留策略（RP）。
• 必须考虑多站点高可用性。
• 位置数据显示低值密度，因此在线分析处理 (OLAP) 不是关键要求。

数据存储解决方案示意图

我们的存储系统经历了一系列变化，如下所示。

最初我们使用运行在小型机上的Oracle将数据存储在 366 个单表分区中（每个分区只包含一张表，单表存储一天的时间序列总数据），只能存储一年的数据（删除数据按分区）。使用 Oracle 时，我们按日期对表进行分区，并将分区编号为 1 到 366 以进行查询。如果我们未能及时删除历史数据，例如 2020.7.21 和 2021.7.21 将被分配到同一个分区中。

2017年，为了解决Oracle方案存在的问题，我们决定采用Mycat搭建MySQL集群。

到2019年，运营部提出针对不同业务的RP要针对使用场景进行量身定制，因此我们决定为不同的业务系统创建独立的数据库。但是，配置复杂、管理困难等问题开始出现。

时间到了 2020 年，我们启动了一个测试项目来验证TiDB的写入性能和稳定性。遗憾的是，TiDB 并不是专门针对时间序列数据的数据库，所以它在车联网场景中的不足是相当显着的。

2020 年 10 月，我们决定寻找专业的位置数据存储解决方案。

痛点

Mycat+MySQL作为位置数据存储解决方案已经服务了2年多了，但还是有很多痛点：

• 首先，Mycat 是一种基于 MySQL 的中间件，不支持自动伸缩。
• 执行数据删除很复杂，如果需要根据客户的特定要求定制数据生命周期，设计不同的保留策略非常不方便。
• 配置 Mycat 涉及许多痛苦而复杂的操作。
• Mycat+MySQL 已成为业界过时的解决方案。

去年，我们进行了一个测试项目，以检验 TiDB 在车联网场景中的性能，并获得了一些见解，如下所示。

优点：

• 高效的写入性能和水平可扩展性
• 高可用性和容错设计
• 支持多站点和多个数据中心

瓶颈：

• 需要固态驱动器（SSD），存储成本高，因此以低价值密度存储海量数据并不划算。
• TiDB 无法为客户提供量身定制的 RP

基于车联网场景，位置数据表现出以下属性：

• 写入吞吐量大（每秒可达8000条记录）
• 数据只用于查询，无需改动
• 海量数据（每天超过 2 亿条数据记录）
• 查询最近生成的数据
• 无需数据库事务支持
• 只需要简单的查询（不需要 JOIN 查询）
• 根据客户要求定制RP

参考上面提到的属性，我们可以得出结论，传统的关系数据库管理系统（RDMS）很难处理位置数据。尽管如此，我们发现时间序列数据库可能是一个更好的答案。

研究与选择

出于寻找更好解决方案的目的，我们对物联网和联网汽车行业中流行的时间序列数据库进行了研究。备注如下。

• InfluxDB：业界领先的时序数据库，社区版在实际使用中不支持集群和高可用设计。
• Prometheus：虽然 Prometheus 是目前流行的时序数据库之一，但它的“Pulling”设计并不适用于我们的使用场景。
• TDengine：一个开源的时间序列数据库，具有行业领先的写入和存储效率，拥有专业且活跃的开发者社区以及众多可靠的用例。

通过谨慎的决策过程，我们的团队最终决定专注于 TDengine。

在 TDengine 上测试

TDengine 的部署非常简单。TDengine的写入速度与连续向SSD写入数据一样快，同时其压缩算法呈现出高性能的存储效率，有助于节省大量存储空间。此外，TDengine 使用用户友好的类似 SQL 的语法。

对于定制化RP设计的要求，可以通过配置参数“ keep ”和参数“ days ”来实现。

在测试中，我们基于2000万条数据记录的数据集测试了TDengine的存储效率。下面提供了 MySQL 表模式：

如下图所示，测试结果表明TDengine在存储效率方面明显优于MySQL。

因此，鉴于测试结果，我们决定使用 TDengien 作为 Mycat+MySQL 的替代方案。

下面附上TDengien在全球架构大会上的精彩分享内容，资料不全，有兴趣可以私信获取完整文档