毫秒级返回数据，58同城 DBA 团队选择 TDengine 解决传感器数据处理难题

小 T 导读：在 58 同城的驾考业务上，需要存储分析驾校教练车传感器产生的数据，这是典型的时序数据场景，开发人员对原有的 TiDB 性能并不是很满意，因此 DBA 团队开始调研更具针对性的时序数据库。基于自身的业务需求，他们在 6 款时序数据库中选择了 TDengine Database，在经过深入的调研测试之后，开始部署实践，最终业务痛点问题得到了解决。

企业简介

作为中国领先的生活服务平台，58 同城业务覆盖招聘、房产、汽车、二手、本地生活服务及金融等各个领域。在用户服务层面，58 同城不仅是一个信息交互的平台，更是一站式的生活服务平台，同时也逐步为商家建立起全方位的市场营销解决方案。目前，58 同城已经成为中国全面服务本地商户与用户的线上商业服务平台。

项目介绍

58 同城业务覆盖了众多不同的领域，比如 58 同城主站、安居客、赶集网、数科公司、中华英才网、驾校一点通等，基于此，DBA 团队也引入了不同类型的数据库来支持上层业务，其中包括 MySQL、Redis、MongoDB、ELK、TiDB、StarRocks、NebulaGraph，在服务规模上能达到每日请求几万亿次。在以上数据库服务矩阵中，可以发现缺少了处理时序数据相关的数据库。

在我们的驾考业务上，需要存储分析驾校教练车传感器产生的数据，是典型的时序数据。该场景会涉及高并发插入，数据处理特点为写多读少，有特定时间段的聚合分析。我们此前使用的是 TiDB 存储，但开发人员对 TiDB 的性能不是很满意，业务具体需求是：日增千万数据，毫秒级插入，并在1秒钟以内返回3万条符合时间分析条件的数据。

但这也不能怪 TiDB，目前在数据库选型上其实就是不匹配的，这个业务场景是典型的车联网设备传感器数据，而 TiDB 和时序类型数据库（Time-Series Database）是两种完全不同的数据库服务，在功能侧重上也有较大区别。事实上，当前没有一种数据库可以满足所有需求场景，“All In xxDB” 这种脱离了场景谈数据库选型都是没意义的。为了给上层业务提供更贴合的数据库服务，我们的 DBA 团队开始调研时序数据库。

一、从需求看数据库选型

根据上述需求，DBA 团队调研了如下六款时序数据库，调研结果如下：

InfluxDB：最流行的时序数据库，单机开源，高可用集群收费
OpenTSDB：集群方案成熟，依赖 HBase，运维复杂，聚合分析能力弱
Prometheus：维护简单，集成监控和报警功能，但没有集群解决方案，聚合分析能力较弱
DolphinDB：运行快，开发快，部署快。闭源，免费版本限制 CPU 和内存大小
ES：集群化，易于使用，维护成本低，但内存耗用高，历史数据计算时性能下降明显
TDengine：性能强悍，国产自主研发，集群版免费，也有附加功能的收费版，还在持续迭代开发

基于以上所考虑的问题点，在经过初步分析后，我们最终选定了对 TDengine Database 进行深入调研测试。

1. 测试环境

集群架构：3 副本 + 负载均衡

容错：先写数据库日志文件，成功后再写数据文件

测试工具：官方 taosdemo

2. 机器配置

3. 写入并发 50：

字段数	绑定参数	设备数	数据量	写入	平均响应时间
3	是	10000	1亿	12120036.84 records/second	2.49ms
3	否	10000	1亿	5932514.09 records/second	6.86ms
20	是	10000	1亿	5883183.51 records/second	5.09ms
20	否	10000	1亿	2078181.61 records/second	19.20ms
20	是	100000	10亿	2673966.95 records/second	174.34ms
20	否	100000	10亿	2621617.26 records/second	57.08ms
50	否	100000	10亿	1216557.03 records/second	57.19ms

4. 服务器最大负载：

	CPU LOAD	内存	磁盘IO	网络
ALL	<10	<7G	<10%	<280M

从以上测试结果可以看出，TDengine Database 在响应时间、插入性能、服务器负载及运维便宜成都上都可以满足上述业务需求。部署和运维细节这里就不展开了。

二、生产环境部署架构与效果展示

在实际生产环境部署上，我们没有采用官方推荐的单机单实例部署，而是单机多实例部署，为三节点+三副本架构，监控上使用的是 TDinsight + Grafana。

在实际应用上，基于业务情况我们调低了步长和子表数，希望可以达成更高的并发能力。针对之前应用 TiDB 时的痛点问题，业务方反馈在代码未调整的情况下TDengine可以在1秒内返回所需数据，业务代码调整过后在300毫秒内即可返回所需数据。此外借助 TDengine 的已有函数，很轻松就打通了向量分析的逻辑，避免再去编写业务代码，省时省力。

当然，在应用过程中，我们也遇到了一些问题，在此也汇总一下，作为给 TDengine 研发团队的一些改进建议：

我们使用的单机多实例部署方式，在目前已发布版本中还没有很好的命令支持，日志输出的位置也需要显式指定。业务的发展会有不确定的变化，从资源成本角度来看，应该初期可预估、后期可调整，希望未来 TDengine 也能有更灵活多变的部署方式。

TDinsight 可以很直观地监控 TDengine 的性能，但一个视图模式下只对一套集群，如果有几十套、几百套集群，集成的 TDinsight 组件目前还无法添加，只能手动一个个修改 Grafana 视图变量，这个比较麻烦，建议官方优化集成的 TDinsight 组件。
在进行 taosdump 导入时，更换库名后无法利用原库名的备份文件进行导入，建议官方修改支持。

三、写在最后

基于 58 集团众多的业务场景，TDengine Database 已经成为 DBA 团队为上层业务提供数据库服务矩阵的可选方案之一，让时序数据也有了专业的处理方案，后续监控服务的数据也会陆续转移到 TDengine 进行存储。未来我们将会与 TDengine 一起探索更多维度的生态合作，为集团提供更好的底层数据服务支持。

作者简介

张广元，58 集团 DBA，十年数据库运维管理老兵一枚。

想了解更多 TDengine Database的具体细节，欢迎大家在GitHub上查看相关源代码。