关于tdengine:复杂场景从OpenTSDB迁移到TDengine的最佳实践

在上一篇文章中，咱们介绍了运维监控场景下，如何从 OpenTSDB 迁徙到 TDengine。

如果利用特地简单，或者应用领域并不是运维监控场景，本文将更加全面深刻地介绍将 OpenTSDB 利用迁徙到 TDengine 的高级话题。

其余场景的迁徙评估与策略

1、TDengine 与 OpenTSDB 的差别

本节将具体介绍 OpenTSDB 与 TDengine 在零碎性能层面上存在的差别。

读完本节之后，你能够全面地评估是否能将某些基于 OpenTSDB 的简单利用迁徙到 TDengine 上，以及迁徙之后应该留神的问题。

TDengine 以后只反对 Grafana 的可视化看板出现，所以如果利用中应用的是其余看板（例如 TSDash、Status Wolf 等），那么临时无奈间接迁徙到 TDengine，须要将其从新适配到 Grafana 才能够失常运行。

截止到 2.3.0.x 版本，TDengine 只可能反对 collectd 和 StatsD 作为数据收集汇聚软件，当然前面会陆续提供更多的数据收集聚合软件的接入反对。如果收集端应用了其余类型的数据汇聚器，则须要适配到这两个数据汇聚端系统，能力失常写入。除了上述两个数据汇聚端软件协定以外，TDengine 还反对通过 InfluxDB 的行协定和 OpenTSDB 的数据写入协定、Json 格局将数据间接写入，能够重写数据推送端的逻辑，应用 TDengine 反对的行协定来写入数据。

此外，如果利用中应用了 OpenTSDB 的以下个性，在迁徙之前还须要理解以下注意事项：

1. /api/stats：如果利用中应用了该项个性来监控 OpenTSDB 的服务状态，并在利用中建设了相干的逻辑来联动解决，那么这部分状态读取和获取的逻辑须要从新适配到 TDengine。TDengine 提供了全新的解决集群状态监控机制，来满足利用对其进行的监控和保护的需要。
2. /api/tree：如果依赖于 OpenTSDB 的该项个性来进行工夫线的层级化组织和保护，那么便无奈将其间接迁徙至 TDengine。TDengine 采纳了数据库 -> 超级表 -> 子表这样的层级来组织和保护工夫线，归属于同一个超级表的所有的工夫线在零碎中同一个层级，然而能够通过不同标签值的非凡结构来模仿应用逻辑上的多级构造。
3. Rollup And PreAggregates：采纳了 Rollup 和 PreAggregates，须要利用来决定在适合的中央拜访 Rollup 的后果，在某些场景下又要拜访原始的后果，这种构造的不透明性让利用解决逻辑变得极为简单而且齐全不具备移植性。咱们认为这种策略是时序数据库无奈提供高性能聚合状况下的斗争与折中。TDengine 暂不反对多个工夫线的主动降采样和（时间段范畴的）预聚合，因为 其领有的高性能查询处理逻辑，即便不依赖于 Rollup 和（时间段）预聚合计算结果，也可能提供很高性能的查问响应，而且让你的利用查询处理逻辑更加简略。
4. Rate: TDengine 提供了两个计算数值变化率的函数，别离是 Derivative（其计算结果与 InfluxDB 的 Derivative 行为统一）和 IRate（其计算结果与 Prometheus 中的 IRate 函数计算结果统一）。然而这两个函数的计算结果与 Rate 有轻微的差异，但整体上性能更弱小。此外，OpenTSDB 提供的所有计算函数，TDengine 均有对应的查问函数反对，并且 TDengine 的查问函数性能远超过 OpenTSDB 反对的查问函数， 能够极大地简化利用解决逻辑。

通过下面的介绍，置信你应该可能理解 OpenTSDB 迁徙到 TDengine 带来的变动，这些信息也有助于你正确地判断是否能够承受将利用迁徙到 TDengine 之上，体验 TDengine 提供的弱小的时序数据处理能力和便捷的应用体验。

2、迁徙策略

首先将基于 OpenTSDB 的零碎进行迁徙波及到的数据模式设计、零碎规模估算、数据写入端革新，进行数据分流、利用适配工作；之后将两个零碎并行运行一段时间，再将历史数据迁徙到 TDengine 中。当然如果你的利用中有局部性能强依赖于上述 OpenTSDB 个性，同时又不心愿停止使用，能够思考放弃原有的 OpenTSDB 零碎运行，同时启动 TDengine 来提供次要的服务。

数据模型设计

一方面，TDengine 要求其入库的数据具备严格的模式定义。另一方面，TDengine 的数据模型绝对于 OpenTSDB 来说又更加丰盛，多值模型可能兼容全副的单值模型的建设需要。当初让咱们假如一个运维监控场景，咱们应用了 collectd 收集设施的根底度量（metrics），蕴含了 memory、swap 和 disk 等几个度量，其在 OpenTSDB 中的模式如下：

TDengine 要求存储的数据具备数据模式，即写入数据之前需创立超级表并指定超级表的模式。对于数据模式的建设，有两种形式来实现此项工作：

1）充分利用 TDengine 对 OpenTSDB 的数据原生写入的反对，调用 TDengine 提供的 API 将（文本行或 JSON 格局）数据写入，并自动化地建设单值模型。采纳这种形式不须要对数据写入利用进行较大的调整，也不须要对写入的数据格式进行转换。在 C 语言层面，TDengine 提供了 taos_insert_lines 来间接写入 OpenTSDB 格局的数据（在 2.3.x 版本中该函数对应的是 taos_schemaless_insert）。其代码参考示例请参见安装包目录下示例代码 schemaless.c。

2）在充沛了解 TDengine 数据模型的根底上，联合生成数据的特点，手动建设 OpenTSDB 到 TDengine 的数据模型调整的映射关系。TDengine 可能反对多值模型和单值模型，思考到 OpenTSDB 均为单值映射模型，这里举荐应用单值模型在 TDengine 中进行建模。

• 单值模型

具体步骤如下：将度量（metrics）的名称作为 TDengine 超级表的名称，该超级表建成后具备两个根底的数据列—工夫戳（timestamp）和值（value），超级表的标签等效于 度量 的标签信息，标签数量等同于度量 的标签的数量。子表的表名采纳具备固定规定的形式进行命名：metric + '_' + tags1_value + '_' + tag2_value + '_' + tag3_value ... 作为子表名称。

在 TDengine 中建设 3 个超级表:

create stable memory(ts timestamp, val float) tags(host binary(12)，memory_type binary(20), memory_type_instance binary(20), source binary(20));
create stable swap(ts timestamp, val double) tags(host binary(12), swap_type binary(20), swap_type_binary binary(20), source binary(20));
create stable disk(ts timestamp, val double) tags(host binary(12), disk_point binary(20), disk_instance binary(20), disk_type binary(20), source binary(20));

对于子表应用动静建表的形式创立如下所示：

insert into memory_vm130_memory_bufferred_collectd using memory tags(‘vm130’,‘memory’, 'buffer', 'collectd') values(1632979445, 3.0656);

最终零碎中会建设 340 个左右的子表，3 个超级表。须要留神的是，如果采纳串联标签值的形式导致子表名称超过零碎限度（191 字节），那么须要采纳肯定的编码方式（例如 MD5）将其转化为可承受的长度。

• 多值模型

如果想利用 TDengine 的多值模型能力，须要首先满足以下要求：不同的采集量具备雷同的采集频率，且可能通过音讯队列同时达到数据写入端，从而确保应用 SQL 语句将多个指标一次性写入。将度量的名称作为超级表的名称，建设具备雷同采集频率且可能同时达到的数据多列模型。子表的表名采纳具备固定规定的形式进行命名。上述每个度量均只蕴含一个测量值，因而无奈将其转化为多值模型。

数据分流与利用适配

从音讯队列中订阅数据，并启动调整后的写入程序写入数据。

数据开始写入继续一段时间后，能够采纳 SQL 语句查看写入的数据量是否合乎预计的写入要求。

统计数据量应用如下 SQL 语句：

select count(*) from memory

实现查问后，如果写入的数据与预期的相比没有差异，同时写入程序自身没有异样的报错信息，那么可用确认数据写入是残缺无效的。

TDengine 不反对采纳 OpenTSDB 的查问语法进行查问或数据获取解决，然而针对 OpenTSDB 的每种查问都提供了对应的反对。具体能够参考相干文档。

TDengine 反对以规范的 JDBC 3.0 接口来操纵数据库，也能够应用其余类型的高级语言的连接器来查问读取数据，以适配利用。具体的操作和应用帮忙也请参阅用户手册。

历史数据迁徙

1、应用工具主动迁徙数据

为了不便历史数据的迁徙工作，咱们为数据同步工具 DataX 提供了插件，可能将数据主动写入到 TDengine 中，须要留神的是 DataX 的自动化数据迁徙只可能反对单值模型的数据迁徙过程。DataX 具体的应用形式及如何应用 DataX 将数据写入 TDengine 请参见其应用帮忙手册 github.com/taosdata/datax。

2、手动迁徙数据

如果须要应用多值模型写入数据，就须要自行开发一个将数据从 OpenTSDB 导出的工具，而后确认哪些工夫线可能合并导入到同一个工夫线，再将能够同时导入的工夫通过 SQL 语句写入数据库中。

手动迁徙数据须要留神以下两个问题：

1）在磁盘中存储导出数据时，磁盘须要有足够的存储空间以便可能充沛包容导出的数据文件。为了防止全量数据导出后导致磁盘文件存储缓和，能够采纳局部导入的模式，对于归属于同一个超级表的工夫线优先导出，而后将导出局部的数据文件导入到 TDengine 零碎中。

2）在零碎全负载运行下，如果有足够的残余计算和 IO 资源，能够建设多线程的导入机制，最大限度地晋升数据迁徙效率。思考到数据解析对于 CPU 带来的微小负载，须要管制最大的并行任务数量，以防止因导入历史数据而触发的零碎整体过载。

因为 TDegnine 自身操作繁难性，所以不须要在整个过程中进行索引保护、数据格式的变动解决等工作，整个过程只须要程序执行即可。

当历史数据齐全导入到 TDengine 当前，此时两个零碎处于同时运行的状态，之后便能够将查问申请切换到 TDengine 上，从而实现无缝的利用切换。

🌟点击摸索 taosAdapter！