小 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，十年数据库运维管理老兵一枚。
