小 T 导读：为了实现业务更好地发展，我们有时必须做出数据库替换的决定，这时要特别慎重。想要真正了解一款数据库产品，调研和测试必不可少，需要耗费大量时间和精力。在本篇文章中，作者描述了自己与 TDengine Database 从初识到了解再到深交的经历，将自己从调研阶段到实际应用之后的问题、效果等做成了经验汇总，分享出来以作参考。
一、与 TDengine 的开始
实际上，我从事 Java 开发的时间只有三年左右，在这个阶段中，因为我所涉及的业务场景和行业都用不到时序数据库，所以我完全没有接触和了解过这种类型的产品，仅仅是听说过而已。
2021 年 5 月我换了一个行业，从公司的第一个项目中认识了时序型数据库 InfluxDB ，也算是对这种类型的数据库有了初步的了解。与 TDengine Database 的结识还要从下一个项目说起，这个项目是我全程参与的，项目类型和之前的类似，但技术选型发生了一些变化——要做时序数据库的替换。
最初给我的任务是去调研了解一下 TDengine 是否能贴合我们的业务场景和使用需求，当时我还是比较忐忑的，因为最终调研的结果会直接影响到是否选用 TDengine 、选用结果的好坏、后续代码编程是否会遇到一些不可预测的问题。为了更加了解 TDengine，我开始与涛思数据的小伙伴们打起了交道，与 TDengine 的故事也就此拉开序幕。
二、对 TDengine 进行调研
就个人习惯而言，我首先会通过阅读官网上的官方文档来对一个全新的产品进行学习和了解，并尝试使用。
但我出师不利，刚走到 TDengine 的安装和启动时，就遇到了一个麻烦事（下图所示），这个问题我记在了使用笔记上，所以印象比较深刻。
在此给大家还原下事情的经过，本次操作是在 Linux 环境下，按照文档的提示，我先下载好 TDengine 的安装包进行解压安装，安装后点击启动，输入 taos 命令，当时我进行了一下重新启动（现在也想不清重启的原因了），之后就一直会出现“启动频繁无法启动”的提示，我运用了很多办法都没能解决，后面通过官网上的微信二维码联系上了 TDengine 官方小助手，把这些问题汇报给了技术人员，但不知道是不是我的电脑虚拟机配置机制有问题，反正依然没有找到合适的解决方法，最后我还是选择直接重置了虚拟机，重新安装 TDengine，问题也就迎刃而解了。
做出重置的决定我也是下了很大决心的，由此也可以看出我对 TDengine 进行尝试使用的坚定想法。
在 TDengine 的使用过程中，我遇到了第二个问题，起因是我想通过可视化工具对数据库进行相应的操作，官网文档提供的是利用 IDEA 进行可视化操作，我自己本身也是通过 IDEA 工具进行编程的，按理说应该很顺畅，但我使用 IDEA 有报错信息，无法成功进行可视化操作。其实无法进行可视化操作倒也不会影响我对数据库的操作，但如果可视化实现了就可以更高效地操作数据库了。
为了解决这个问题，我先是进入 TDengine 的 GitHub 开源地址（https://github.com/taosdata/TDengine）寻找了下答案，寻找无果后通过邮件方式将这个问题递交给 TDengine 的研发人员进行相关咨询，所幸经过一系列沟通，这个问题得到了比较好的解决。
通过官方人员发给我的可视化工具（现在我们开发也在经常使用这个工具），可视化问题得到了解决。在我将 TDengine 升级为 2.1.0.0 后，就可以直接通过 IDEA 进行可视化操作了，由此可见，官方确实是在用心听取用户声音，进行产品迭代。
值得一提的是，TDengine 的 SQL 语法还是很赞的，部分的 SQL 语法跟我经常使用的 MySQL 类似，学习成本比较低，很好上手，这部分都是后面根据实际业务场景编写的，遇到问题的时候我们就会及时去官网看看语法，或者去咨询相应的技术人员，不得不说，TDengine 的社区支持力度还是值得称赞的。在这块的学习上，就是超级表和普通表的概念需要我仔细研读下，目前也已经很好地运用在我们的工业业务场景上了。
另外还有一个要解决的问题就是我们自身的 Java 如何和 TDengine 相结合去使用，最终我们是要通过 Java 编程和 TDengine 进行交互的，TDengine 的技术人员很完美的解决了这个问题—— 以 Spring Boot + MyBatis 结合 TDengine 和 JDBC，成功实现了 Demo ，这个在 TDengine 官网上有文档，大家有需要可以直接参考。
最后就是性能方面的考量，从 TDengine 的官网上我们获得了一个可以创建超多数据的 SQL ，首先基于此体验了一下查询速度，速度确实是很快，其次我们发现存储如此庞大的数据量，占用的磁盘空间却并不是非常大，节省了更多存储空间。关于性能的体验，后面我会辅以实际案例再详细说明一下。
三、最终的选择
在进行这么多了解和尝试后，我们也跟 InfluxDB 做了一个对比，综合考量下来，就决定选择 TDengine 了。
首先，超级表普通表的概念非常契合本次项目的业务场景。此前我们的项目是一个站点一个单元对应多个测点，现在是多站点多单元下面对应多个测点，利用超级表普通表就可以做到超级表对应某个站点某个单元，下面跟着 n 个普通表，普通表就是此站点此单元下对应的测点，业务在创建表时会更加便利。
其次，它可以很好地跟 Java 进行结合，通过 JDBC 连接，跟之前操作其他类型的数据库类似，不需要学习太多就可以上手，让没有很深入了解过 TDengine 的人上手也比较快，学习成本显著降低。
第三，搭建集群的成本更低廉。众所周知，InfluxDB 集群功能是闭源的，如果后续业务发展需要用到集群时会带来很大的不便，然而 TDengine 的集群功能是开源的，可以显著降低集群的使用成本，从而减少项目上的使用成本。
第四，从更大的角度说，我们应该响应政策号召多支持国产开源，而且从技术支持的角度来说，选用国外的数据库会让我们非常被动，但是国内的开源数据库是由国人开发和维护的，遇到问题时就可以直接通过微信/邮箱等工具进行交流，沟通上更加有效方便。
第五，性能表现突出，从之前的项目和现在的项目对比来看，部分使用能感受到明显差异，此处表现放在后面的章节上详说，整体上性能表现上是良好的。
四、项目使用上的感受
1. 我们有一个历史数据的查看功能，会直接在页面展示一个历史曲线。之前使用 InfluxDB 的时候，如果你的时间段和时间间隔选择很庞大或者间隔非常细腻的时候，查询数据会变得非常缓慢，更直接的表现就是会直接造成页面的卡死，需要重新打开相应的浏览器。但是用了 TDengine 之后，目前的使用过程中暂时没有发生过这样的现象，并且查询所需要花费的时间非常非常的短，很好地保证了接口的响应速度。
2. TDengine 能够与 MyBatis 很好地结合，开发结合起来非常方便，我们也是写了非常多的工具类的方法实现 TDengine 创建表、获取数据等的便利性，超级表和普通表让我们在创建表时，设计上变得更加简单，也能让测点之间更好地做出区分。
3. 我们的业务场景会涉及到对测点数据进行每秒数据新增和插入的观察，只要通讯在，每秒都会有很多条数据的新增，以目前的表现看 TDengine 性能是 OK 的，后续还要看一下在实际的工作站运行是什么表现。
五、不负彼此的努力
目前我们的项目已经接近尾声，后面本项目会在实际工地进行部署使用，实际的效果需要实践去证明。未来可能还有许多事情要做，比如是否需要搭建集群等。总的来说，因为选择了 TDengine Database，我们的项目很平稳地度过了测试阶段，在 TDengine 的使用上也没有遇到特别大的瓶颈，我相信在后面的合作中，我们对 TDengine 的了解也会更加深入。
整个过程是酸甜苦辣并存的，在这里非常感谢“罗格涛思”和“小 T ”的技术帮助和耐心解答，正是因为有他们的帮助，才让我在此次调研过程中遇到问题能够不慌不忙，最终这些问题也实现了较好地解决，衷心的感谢！
我们与 TDengine 的故事还在继续，敬请期待。
