作者：艾忠元
睿信物联网平台是北京睿信世达自主开发的通用物联网平台，为用户提供从传感器设施、边缘网关、云平台到APP、小程序的一整套端到端物联网SaaS云平台，能够满足用户的通用物联网性能需要；在此基础上构建了智慧水务、智慧消防、智慧环保、智慧农业、智能家居等行业利用组件，满足用户的场景化需要。
平台的整体架构如下。
现状及痛点
目前采纳OpenTSDB进行时序数据的存储，性能上满足现有需要；然而因为OpenTSDB架构简单，体量过重，给开发测试、装置部署以及运维治理等工作带来了不小的麻烦，随着业务的倒退，问题逐步凸显，开始影响工作效率，具体能够演绎为以下几方面：
- 装置难
OpenTSDB不是独立的服务组件，它还要依赖HBase、HDFS、ZooKeeper。须要把这些服务组件全副装置配置好，OpenTSDB能力失常工作，即使是一个纯熟的运维工程师，把这些服务组件全副装置配置一遍，也须要很长时间。 - 调试难
在开发测试过程中，如果呈现问题，须要对OpenTSDB进行日志剖析，甚至可能还须要对HBase、HDFS和ZooKeeper进行全面的日志剖析和问题排查，能力最终定位并解决问题。 - 运维难
在正式环境中，要求集群部署，各种服务都是双份、三份甚至n份部署，各个服务节点之间的关系盘根错节，服务节点和主机数量越多，监控治理就会越难，运维人员的工作累赘也就越重。 - 老本高
老本能够分为两个方面，一个是人力老本高，因为装置、调试、运维的难度减少，造成开发运维人员工作量减少，工作效率变低，从企业经营角度看，人力老本变高；另一个是硬件资源老本高，因为服务节点泛滥，占用的主机、内存和磁盘空间也会很多，购买或租用这些硬件资源须要更多的费用收入。
技术选型
为了解决目前这些问题，咱们决定从新进行技术选型，寻找OpenTSDB的代替计划，降级目前的时序数据库解决方案。进而，要对技术选型进行全面评估，结合实际须要，咱们确定了几个选型要求：
- 开源收费：必须是凋谢源代码的，并且容许收费商用；
- 成熟稳固：具备较长的倒退历史，通过大量我的项目利用实际，经验过工夫的测验；
- 社区沉闷：开发者社区人员多，探讨、问答、征询、推广等线上线下流动频繁；
- 迭代更新：有开发人员始终在保护，一直在迭代更新和公布新版本；
- 性能高：单机能反对每秒10万以上的插入效率，并可能通过扩大硬件反对更高的插入效率；
- 开销低：服务节点少，占用的内存、CPU和磁盘空间少；
- 反对集群：可能集群部署，容量可程度扩大。
通过初步考察，InfluxDB、TimescaleDB和TDengine这3个时序数据库进入了咱们的考查范畴。
InfluxDB
在DB-Engines网站上，InfluxDB处于时序数据库排名的第一位，满足咱们绝大部分的要求，但集群模块闭源，因而被排除在外。
TimescaleDB
TimescaleDB在DB-Engines中的排名也比拟高，简直满足咱们的所有选型要求，然而它是PostgreSQL上的一个时序数据库插件，是基于RDBMS的时序数据库，不是一个纯正的时序数据库；另外，对集群反对不好，不反对程度扩大。
TDengine
和InfluxDB一样，TDengine最后的开源版本也不反对集群，也被排除在外。去年TDengine开源了集群版本后，又进入了咱们的考查范畴。通过各方面的综合考查评估，TDengine满足咱们所有的选型要求，成为技术选型的最终目标。
数据建模
因为是既有系统升级革新，必须合乎现有零碎架构，不能影响现有性能。因而，数据建模必须限定在肯定的范畴内，有肯定的束缚和限度，不能像设计一个新零碎那样有那么大的自由度。总结下来，次要有两方面的束缚和限度：
- schema-free（模式自在）
不须要有create table之类的建表过程，就能够间接进行数据的写入和查问。目前曾经应用了OpenTSDB这种schema-free的数据库，并依照schema-free的形式进行数据的读写，心愿连续这种形式，防止性能和架构上的调整。
- 单列模式
物联网平台的设计初衷是要可能撑持所有的利用场景，不能只思考某一种特定的利用场景，必须设计成一种通用架构，为应用层提供足够的灵便度。因而，咱们将设施和指标之间的关系设计为动静绑定关系，并且可能进行动静绑定配置。
比方，某种液位仪有液位和间隔两个指标，在A场景下只须要采集液位，在B场景下只须要采集间隔。
为了可能撑持设施和指标之间的这种动静绑定关系，咱们采纳了单列模式（也被称为纵表模式或窄表模式），每个指标独自保留一条数据，如果设施有n个指标，就保留n条数据。相同，多列模式（也被称为横表模式或宽表模式）是将设施的所有指标数据存储为一条数据，分不同的列存储不同指标值。
很显然，TDengine不是schema-free的，须要先建表，而后能力进行数据读写，这就冲破了下面的束缚和限度，无奈满足架构上的要求，难道要放弃TDengine？还有没有变通的方法呢？通过一番考察剖析，最终还是找到了解决办法。
上面从三方面进行拆解阐明。
- 通用超级表
TDengine里有超级表的概念，每种设施对应一个超级表，这个超级表只负责存储这种类型的设施数据；因为后面的束缚和限度，咱们必定不能这么用。但能够变通的来用，设计一个可能兼容所有设施类型的通用超级表，把所有设施的数据往这个超级表里装；这样，只须要在零碎装置部署的时候，一次性执行超级表的建表脚本，理论运行时，就不须要再动态创建超级表了。
- 单列模式
TDengine反对单列模式和多列模式，出于插入效率和存储效率的思考，官网举荐多列模式。然而，为了合乎后面的束缚和限度，满足通用场景需要，咱们采纳了单列模式，一条数据中仅存储一个指标值。
联合下面的思路，咱们的数据模型的设计如下（为了不便剖析问题，省去了几个无关的标签）：
数据列蕴含工夫和指标值两列，对应上报工夫和上报的具体值，标签中的指标编码用来对同一个设施下的不同指标做辨别，查问的时候能够用来做条件过滤。
- 主动建表
TDengine中还有一般表的概念（为了和超级表概念辨别开，这里称为一般表），一般表也须要先创立后插入。还好TDengine反对主动建表，能够在插入的时候，顺带建表。于是，咱们就能够利用主动建表语法进行主动建表，屏蔽一般表的建表过程。具体写法如下：
通用超级表，单例模式，再加上主动建表，通过这些方法，咱们把表的概念变得越来越弱化，TDengine逐步被革新成了一个schema-free的数据库，能够依照schema-free的形式来应用TDengine。
这样一来，在不改变架构，不影响性能的前提下，数据建模工作就圆满完成了。
代码革新
在物联网平台现有的架构中，有一个时序数据服务，专门负责对时序数据库进行封装，而后对外提供时序数据的写入和查问服务，物联网平台的其余所有模块都通过这个服务来拜访时序数据库。
有了这样的架构设计，代码革新工作就变得非常简单。只须要改变这个时序数据服务，在现有根底上减少对TDengine的反对，将写入和查问两个性能依照TDengine的JDBC接口进行接口适配，将时序数据的写入和查问切换到TDengine。
通过这种形式，咱们就把TDengine的革新迁徙屏蔽在了时序数据服务外部，下层利用无需关怀，性能上不受任何影响。
数据迁徙工具
降级革新我的项目，须要保留历史数据，须要对历史数据进行数据迁徙。为此，咱们专门开发了一个数据迁徙工具，将OpenTSDB中的历史数据迁徙到TDengine，并且进行了详尽的功能测试。
为了确保海量数据的疾速迁徙，咱们还做了性能优化，并进行了大数据量的压力测试。数据迁徙是降级上线过程中十分重要的一个环节，所以，咱们在这个工具上投入了很多精力，甚至比代码革新自身还多。
降级上线
为了可能平滑顺利地实现降级上线，不影响用户失常应用，咱们制订了具体的迁徙计划，将降级上线分为三阶段实现。
第一阶段：数据迁徙
将革新后的新版本上线，OpenTSDB和TDengine并行运行，同时向两个数据库写入数据，因为OpenTSDB有全量数据，查问申请全副交给OpenTSDB；与此同时，启动数据迁徙工具，将历史数据迁徙到TDengine，待数据迁徙实现，进入到第二阶段。
第二阶段：试运行
OpenTSDB和TDengine仍然并行运行，也同时向两个数据库写入数据；数据迁徙曾经实现，TDengine中曾经具备全量数据，因而，查问申请全副切换到TDengine。察看两周左右的工夫，没有发现任何问题，进入到第三阶段。
第三阶段：正式上线
TDengine通过试运行一切正常，性能和性能都没有问题，于是咱们将OpenTSDB进行运行，数据只向TDengine写入，OpenTSDB占用的资源全副回收。
到此为止，降级上线全副实现。
革新成果
迁徙到TDengine后，成果非常明显，硬件资源缩小到原来的1/5，效率有了显著的晋升。随着存储规模的一直变大，这种改善和晋升成果会越来越显著。此外，在运维治理、费用收入、开发测试等方面也有了很大的改善。
- 开发人员当初能够本人电脑上搭建一套环境，轻易折腾，不必放心跑不起来，也不必放心影响他人；
- 性能测试的时候，用配置低一些的机器也没问题，照样能做出压测成果；
- 遇到技术难题，原来通过Google、百度、StackOverflow寻找答案，当初能够间接在官网渠道https://github.com/taosdata/TDengine提issue，也能够在TDengine的技术社区发问，TDengine的技术专家亲自回答，响应十分快；
- TDengine的体积小，只有几M，上传起来十分快，有些私有化部署我的项目，不容许拜访外网，只能手动上传，体积小的劣势就非常明显；
- 装置部署简略，配合Docker容器，能够在几分钟内实现装置部署；
- 经营监控工作变简略了，只须要对TDengine的几个过程进行监控；
- 占用的磁盘空间显著变小了，缩小到原来的1/5；
- 应用的主机缩小到原来的1/5，相应的费用收入也缩小了。
总结
此次降级革新总体进行得比较顺利，但过程中也有一些挫折，尤其是在数据建模的时候遇到了一些艰难。方法总比艰难多，通过一些办法和技巧，咱们把TDengine革新成了schema-free的数据库，满足了物联网平台的要求，最终实现了降级革新。
目前，曾经撑持起了所有物联网设施上报的数据，同时撑持起了应用层的各种利用场景。
革新后的成果显著，硬件资源缩小为原来1/5，开发、测试、运维、治理、收入等方面都有显著的改善和晋升。
咱们应用到的性能还比较简单，次要是插入、间断查问以及降采样查问，对于物联网平台来说根本够用。UNION、GROUP BY、JOIN、聚合查问等性能临时还未应用到，这些性能对于大数据分析的场景十分有用，未来在一些大数据我的项目里能够尝试应用，用来代替Hadoop全家桶。
此外，应用过程中遇到一些问题，心愿改良：
- JDBC-JNI不是纯Java的，依赖一个动静库，给装置部署带来不少麻烦；
- 起初通过JDBC-RESTful解决了这个问题，然而两头多了一层RESTful Connector，性能会低一些；
- 最现实的做法，还是用纯Java写一个直连后端服务的JDBC Driver；
- 客户端是命令行形式，对于开发者不是很敌对，尤其是一些高级开发者，或者是用惯了图形界面的开发者；
- 图形界面，语法高亮，语法查看，这些性能还是很香；
- 尽管目前有两个社区开发者提供的GUI，当然官网能提供反对的话是最好不过了。