作者介绍: 薛超，中移物联网数据库运维高级工程师，10 年数据库运维经验，2017 年退出中移物联网，负责数字化产品部数据库相干工作，专一于数据库优化和推动架构演进；近年来次要钻研国产新型数据库，目前所在部门全副业务曾经去 ”O”，在此过程中，积攒了大量新型数据库的运维教训。
对于中移物联网
中移物联网有限公司是中国移动通信集团有限公司出资成立的全资子公司。公司依照中国移动整体策略布局，围绕“物联网业务服务的撑持者、专用模组和芯片的提供者、物联网专用产品的推动者”的策略定位，专业化经营物联网专用网络，设计生产物联网专用模组和芯片，打造车联网、智能家居、智能穿戴等特色产品，开发经营物联网连贯治理平台 OneLink 和物联网开放平台 OneNET，推广物联网解决方案，造成了五大方向业务布局和物联网“云 - 网 - 边 - 端”全方位的体系架构。
业务背景
车联网是中移物联网的一个十分典型的场景。在这种场景下，咱们须要存储车联网设施的轨迹点，还要反对对轨迹进行查问。
轨迹数据有几个典型的特点：
- 高频写入，每天写入约两亿条轨迹数据；
- 低频查问，通常是由用户触发，查问最近几天的轨迹；
- 企业用户有定制轨迹存储周期的需要；
- 须要思考双活容灾场景；
- 不针对 OLAP 需要，数据价值密度低。
存储系统演进过程
咱们的存储系统也经验了几个阶段的演进。
最后咱们应用 Oracle 小型机单表分区存储数据，建设了 366 个分区，因而也只有一年的存储容量（按分区来删除数据）。应用 Oracle 时，咱们按日期分区，查问的时候带入 1 -366 的分区数字进行查问，如果不清理历史数据，2020.7.21 和 2021.7.21 会在一个分区内，不便于管理。
2017 年响应团体去 IOE 的要求，轨迹数据不能再应用高性能的 Oracle，通过研发和运维团队的调研，决定应用 Mycat 来搭建 MySQL 集群。
2019 年产品对各个子业务提出了不同存储周期的要求，面向行业的业务存储工夫要求更长。因而咱们按子业务做了拆分，每个子业务应用本人的独立库。然而，这个时候 Mycat 配置简单、难以治理的问题就开始浮现了。
到了 2020 年，运维团队开始调研国产数据库 TiDB，为了验证 TiDB 的写入性能和稳定性，咱们开始将轨迹数据同时写入到 TiDB。
2020 年 10 月，咱们开始重新考虑轨迹存储计划。
原有计划的痛点
轨迹服务的 Mycat 集群计划自 2017 年上线后曾经稳固运行 2 年多，然而在理论商用过程中，咱们还是发现了很多问题：
- 首先是扩容危险，Mycat 自身是一个构建在 MySQL 之上的比较简单的中间件，并不反对主动扩容；
- 数据删除比拟麻烦，如果每个客户都要定制本人的存储年限，很难设计；
- Mycat 中间件配置简单，每个逻辑库都会有大量简单的配置；
- 整体计划曾经被业内淘汰。
之后咱们配合运维团队在轨迹存储上尝试了 TiDB，通过几个月的写入测试，验证了 TiDB 的写入性能和运行稳定性。
长处：
- 写入性能强，扩容简略；
- 反对高可用，灾备欠缺；
- 反对两地多核心。
问题：
- 要求应用 SSD，存储老本过高，不适宜轨迹存储这种低价值的数据；
- 不能解决行业客户轨迹数据存储周期定制化的须要。
咱们无妨再来看一下 轨迹数据存储的典型特点：首先是轨迹数据写入量大，每天约 2 亿条轨迹，峰值写入 8000 条 / 秒；其次是企业对数据存储周期有定制化需要（比方 1 年、3 年或者 5 年等）；最初还要反对多核心双活个性。而传统关系型数据库很难满足这些需要。
轨迹数据自身也很有特点：
- 数据只查问不批改；
- 海量数据写入；
- 查问工夫次要集中在最近一段时间；
- 无需事务反对；
- 查问形式简略，设施之间无关联，不须要 join 查问；
- 客户心愿轨迹存储工夫足够长。
咱们发现，这个特点人造适宜时序数据库。
时序数据库选型
咱们钻研了业界比拟有代表性的几款时序数据库产品。
- InfluxDB
在成都的资源池团队有实际，在应用社区版的时候遇到了一些问题，而且该版本不反对集群和高可用。
- Prometheus
尽管也是支流时序数据库，然而其独特的拉数据形式并不适宜咱们的场景，而且其“联邦”集群的机制高可用存疑。
- TDengine
国产开源的物联网大数据平台。
在参考 DB-Ranking 上的排名数据和部门运维专家的意见后，咱们进行了局部调研。发现市场上尽管时序数据库百花齐放，然而都没有完满的抉择。在评审会议完结后，大家决定把重点放到 TDengine 上，发现这款产品意外的很不错。运维团队主动出击，还失去了涛思数据官网的收费技术支持。
TDengine 试用初体验
TDengine 部署非常简单，而且写入速度极高，靠近硬盘的间断写入性能。TDengine 的高效压缩算法，能够节俭大量存储空间。SQL 语法，应用非常简单。
数据存储周期的定制化需要，也很容易通过 TDengine 满足。
TDengine 的存储效率也十分高，在选型过程中，咱们进行了 2000 万条数据的模仿测试。上面是 MySQL 表构造，一共 22 个字段和一个联结索引。
下图是插入 2000 万条数据之后，MySQL 和 TDengine 占用的磁盘空间比照状况。
能够发现，在节俭存储空间方面，TDengine 的劣势极为显著。
因而，咱们决定将轨迹数据的存储迁徙到 TDengine。
库表设计
在库表设计上，咱们使用了 TDengine 主动建表的个性，每个终端设备产生的轨迹点位数据在第一次入库的时候主动创立子表，咱们只须要建一个 database 和一个存储轨迹的 STable 就高枕无忧了。
咱们应用的 STable 构造如下：
create stable device_statushis (
pos_time TIMESTAMP,
sample_time TIMESTAMP,
record_time TIMESTAMP,
online_status SMALLINT,
alarm_status SMALLINT,
pos_method SMALLINT,
pos_precision SMALLINT,
pos_longitude DOUBLE,
pos_latitude DOUBLE,
pos_altitude DOUBLE,
pos_speed FLOAT,
pos_direction FLOAT,
acc_forward FLOAT,
acc_side FLOAT,
acc_verticle FLOAT,
rollover_level SMALLINT,
power_voltage FLOAT,
acc_status SMALLINT,
satellite_num SMALLINT
)
tags(device_id BINARY(32)
) ;建表实现之后，咱们还要将历史数据迁徙到 TDengine 中。
咱们大概有 30T 的数据须要从 Mycat 集群迁徙到 TDengine，因而咱们写了一个小工具来实现这项工作，只用了 2 天左右的工夫实现了全副迁徙。
零碎的整体架构如图所示：
整体性能
在迁徙到 TDengine 之后，性能体现十分不错：写入峰值 1.2-1.3w/s ; 存储大概只有 MySQL 的 1 /7，查问性能也很突出，单设施单日查问在 0.1s 以内能够返回后果。
将来瞻望
目前 TDengine 可能很好地解决咱们的需要。将来咱们会尝试在更多场景下尝试 TDengine，进一步开掘其后劲。