作为入场较早的时序数据库产品，OpenTSDB 占据了一定的先机，在一些企业的时序数据场景中被广泛应用，但从实际效果来看，反馈到性能体现和业务需求上，却远没有想象中那么美好。
在至数物联网平台至数摇光改造前，数据库架构就采用了 OpenTSDB + MySQL 结合的方式实现，目标是帮助医疗机构实现有源设备的高效管理、提效降耗，但由于 OpenTSDB 无法满足复杂查询场景，因此 80% 的场景指标只能基于 MySQL 数据库来实现，这样带来的问题就是 MySQL 数据库的数据增长迅速，需要定时做冷热数据分离及数据库表维护动作。
对于至数摇光来说，OpenTSDB 作为一个大而全的数据库，在实际运作中还是稍显笨重，伴随着业务需求的不断迭代及数据量的不断上涨，其局限性也日益凸显，系统的架构升级和改造工作日渐迫切。随后通过一系列调研，至数摇光决定将数据从 OpenTSDB 迁移至更为专业且完全自主研发的国产时序数据库 TDengine 上。
改造后有大约 80% 左右的指标模型放到了 TDengine 中，20% 左右的主数据或维表数据存放在 MySQL 中。相较于改造前的 80% 指标模型存放在 MySQL 中，20% 指标数据存放在 OpenTSDB 中，结果刚好进行了颠倒，服务器资源使用情况也有所下降。
改造前后查询性能对比如下，TDengine 彻底弥补了 OpenTSDB 无法满足复杂查询场景的缺点：
在应用 OpenTSDB 后“踩坑”的企业，至数摇光并不是独一例，顺丰科技、睿信物联网同样遭遇了此类问题。
顺丰科技是围绕 OpenFalcon 搭建的大数据监控平台，但 OpenFalcon 以 rrdtool 作为数据存储，不适合做全量监控数据的存储，他们便采用了 OpenTSDB+HBase 作为大数据监控平台全量监控数据的存储方案，但随着平台接入数据量的增长，在此数据库方案下痛点问题频发，包括依赖多、使用成本高和性能不能满足等问题。
顺丰科技采用 4 节点 OpenTSDB + 21 节点 HBase 作为全量监控数据存储集群，压缩后每天仍需要 1.5TB（3副本）左右空间存储，整体成本较高。在性能上，OpenTSDB 作为全量监控数据存储方案，在写入方面性能基本满足需求，但是在日常大跨度和高频次查询方面已无法满足要求。一方面，OpenTSDB 查询返回结果慢，在时间跨度比较大的情况下需要十几秒；另一方面，OpenTSDB 支持的 QPS 较低，随着用户规模的扩大稳定性受到挑战，容易引发系统崩溃导致整个服务不可用。
后面通过对 IoTDB、Druid、ClickHouse、TDengine 等时序数据存储方案进行调研，最终顺丰科技选择将数据迁移至 TDengine。完成改造后，大数据监控平台摆脱了对大数据组件的依赖，有效缩短了数据处理链路，稳定性有了极大提升；理想情况下，集群写入速度最高达到 90W 条/s 的写入速度；在使用预计算函数情况下，查询 p99 都在 0.7 秒以内；服务端物理机由 21 台降至 3 台，每日所需存储空间为 93 GB（2 副本），同等副本下仅为 OpenTSDB+HBase 的约 1/10。
同样，此前睿信互联网也是采用 OpenTSDB 进行时序数据的存储，但由于 OpenTSDB 架构复杂，体量过重，给开发测试、安装部署以及运维管理等工作带来了不小的麻烦，随着业务发展，出现的调试难、运维难、成本高等诸多难题严重影响着工作效率。迁移到 TDengine 后，硬件资源减少到原来的 1/5，效率也有了明显的提升；开发人员可以在自己电脑上搭建一套环境，随便折腾，不用担心跑不起来，也不用担心影响别人；在性能测试的时候，用配置低一些的机器也没问题，照样能做出压测效果；运营监控工作也变的更简单了，只需要对 TDengine 的几个进程进行监控……
从这些企业的亲身经历来看，也就不难理解为什么他们会放弃继续使用 OpenTSDB 了。
