目录
使用场景
车联网是典型场景。在这样的场景下，存储和查询汽车物联网设备产生的大量位置数据是非常有必要的。
位置数据具有以下重要特征：
写入频率高：每天需要写入超过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在全球架构大会上的精彩分享内容，资料不全，有兴趣可以私信获取完整文档