公司简介

北京金海乐游软件有限公司是一家以计算机软件架构开发为核心，实施计算机软硬件系统集成的现代科技企业。我司从事交通运输行业系统软件研发，技术覆盖且不限于 JAVA Spring框架（可选技术框架：C/C++、Python、Go）行业业务逻辑实现、TransCAD\TransModeler\超图\Arcgis等商业软件的二次开发和算法实现、大数据分析及数据中台、交通资产管理。

作者信息

王扬北京金海乐游软件有限公司技术主管

项目背景

某市级管理单位为了强化全市交通运输管理，统筹综合交通发展，提升交通运行和管理效率，建立了大交通数据资源管理系统及相关应用 “一图一库”。其中“一库”部分主要内容包括：数据接入，数据存储，数据共享；“一图”部分主要内容包括：GIS信息及其关联数据信息在二维、三维地图上的形象表达。
该大交通数据资源管理系统本质是为某市交通运输行业建设高效可用的行业数据中台系统，其基本架构如下：

我们的需要

在交通运输行业的数据中台建设中，存在大量的时序数据应用场景，其中最为关键的就是车辆运行时序数据的存储与使用。如下图所示，综合交通运行监测系统中，GPS时序数据是及其重要的数据资源：

由出租车、网约车、公交车、轨道、水运、长短客运、两客一危、铁路运输的车辆船舶实时上传运行相关数据，均具备时序数据的特征，每日的入库数据量轻松突破亿级大关，一线城市或省级区域的车辆船舶运行数据甚至可达到数亿甚至数十级别，如何高效的将时序类数据入库成为交通运输行业数据中台的一个核心诉求。

交通运输行业信息化业务中有对于车辆的实时位置高效查询的核心诉求。举一个典型的用例，用户需要频繁获得当日上线车船（数万至数十万）的数量、最终位置信息、营业额度等信息，此种类型的查询需要高效的返回结果集（万级车船查询须在秒级）。并且，用户随着信息化的进程，频繁的出现各种新的时序数据查询需求，需要快速高效的实现与部署。

由于交通行业的数据的重要性和敏感性，数据存储的可靠性、可扩张性是极为重要的核心诉求。

为何是TDengine？

选型初始，我们考虑的了三个数据库对象，他们分别是InfluxDB、ClickHouse和TDengine。

InfluxDB：成熟的老牌时序数据库，但是重要的集群功能需要商业版本，考虑到国外商业软件的特殊性质，从审批到付款以及后续安全性，都存在风险。
ClickHouse：俄罗斯开发的高性能数据库，主要问题在于开源社区主要以俄语为主，其非标准化SQL的学习成本较高、集群维护成本高。
TDengine：国产化数据库、中文开源社区，极佳的写入速度，便于维护的集群架构这三点原因最终促使我们选择TDengine作为我们项目的时序数据库。

参考选型文章：

落地过程

集群架构落地

使用5台服务器搭建TDengine的dnode集群，mnode与数据库的副本数均设定为3。

在集群的设定初期，由于当前版本mnode个数的缺省值由之前的3个变更成为了1个，系统mnode最初没有副本，使用以下的方法进行安全的重启维护，将mnode总数升级为3个，此方法由官方社群中提供的TDengine集群版升级步骤变更而来：

0.确保集群节点状态正常（show dnodes;），读写无问题。

1.在所有节点停止数据库服务systemctl stop taosd

2.备份数据文件目录下的所有内容到数据文件目录之外。

3.分别cd进入各个节点的数据文件目录

4.tree命令检查所有vnode目录下的wal目录是否为空

5.如果为空，进入步骤7

6.如果非空，启动数据库进程，再关闭，直到wal全部为空。

7.在数据库服务taosd停止的状态下，分别在所有节点修改配置文件，将numOfMnodes的值设为3。

8.分别启动所有节点的taosd服务，systemctl start taosd。

9.show dnodes检查节点状态

10.检查数据。

数据写入架构落地

由于我们的业务开发框架使用的是Srping框架，在使用TAOS-JDBCDriver进行开发时，可以选择两种方式进行数据入库，JDBC-JNI方式或者是JDBC-RESTful方式。在TAOS官网，明确记载了“JDBC-RESTful 性能是 JDBC-JNI 的 50%～90%”，所以，我们选择了JDBC-JNI方式进行多线程入库。

在JDBC-JNI方式中，依然有两种实现方式，在数据库连接池（Hikari、druid）的基础上，原生SQL执行写入或者是使用ORM框架（MyBatis等）执行写入。在设计试运行初期，我们使用了ORM框架进行数据写入，在当前的数据写入量之下，并没有太大的问题。但是，引用涛思数据副总肖波在社区群中沟通中的话：“ORM框架大多数面向关系库开发场景的，每秒几万的吞吐量对它们来说就很大了，但时序写入场景里，这连塞牙缝都不够，设计满足的应用场景不同原因导致它们不适合，但查询影响不大”，我们认识到ORM框架本身可能存在性能瓶颈，因此在未来的版本中，我们使用了数据库连接池（Hikari、druid）+原生SQL执行写入为主要写入模式。

写入效果

项目的目标写入量为1亿条/天，每秒钟写入1158条左右。我们通过TDengine自带的log功能进行分析，确认写入效率。由下图可以看出，五节点构成的集群中，目前瞬时写入能力取不精确的最大值，也就是dn1节点的23107条。log.dn表中数据采集的周期是30秒，由此可知，dn1的实测瞬时最大写入量是770条/秒。加之五节点的集群在分布式插入的架构下，770*5=3850条/秒的数据插入效率是完全可以保障的，完全满足了我们业务需求。至于本集群的插入性能上限，应在此实测值的100倍以上，并且有极大的增长空间。

这里说明一下log.dn表是及其重要的一张TDengine自带的运行状态数据表，我们可以通过此表对TDengine的运行状态进行监视，后面在查询资源占用情况的时候，我们还会用到这张表。log表字段的说明如下图：（据官方社区工作人员表示，后面新版本的TDinsight是更好的监控工具，有机会打算试用一下）

查询效果

所有车辆最新位置信息的查询，这个查询是交通运行监控中的重中之重，在最初，使用何种查询语句实现高效查询极大的困扰了我们，在TDengine社区团队的帮助下，我们利用了隐藏字段名tbname和group by方法，高效的查询了车辆的最新定位信息，从下图中我们可以看到，频繁查询的情况下，接近六万辆车的位置信息，只需要不到1秒的查询时间，简单而又高效，完全符合我们的业务需求：