本文介绍时间序列数据库（Time Series Database，简称TSDB）全量迁移至云原生多模数据库 Lindorm时序引擎的方法。
前提条件
已安装Linux或者macOS操作系统，并且安装以下环境。
已安装Java环境，版本为JDK 1.8及以上。
已安装Python环境，版本为2.x或者3.x。
TSDB的版本为2.7.4及以上。
已创建云原生多模数据库 Lindorm实例并开通时序引擎，请参见创建实例。
背景信息
时序引擎由阿里云自主研发，兼容了TSDB的大部分API。时序引擎相比TSDB具有高性能、低成本、多功能等优势。目前TSDB已停止售卖，建议您将TSDB的全量数据迁移至Lindorm时序引擎。
迁移流程
TSDB全量迁移至Lindorm时序引擎的迁移流程如下：
通过时序数据迁移工具读取TSDB所有的时间线数据，并将数据保存至本地文件。
根据迁移任务配置（指定开始时间、结束时间和时间切分周期）将迁移任务划分成多个时间分组。按照迁移任务配置中指定的oidBatch（即时间线数量）参数将每个时间分组再次划分为多个子读任务，每个子读任务负责读取多个时间线中指定时间范围的数据。
每个子读任务将读取的数据转发给写入端，当一个时间分组内所有的子读任务读取完成后，记录当前时间分组、迁移任务ID和任务状态到任务状态表中（表名的格式为：
internal_datax_jobjobName)。说明时序数据迁移工具支持多任务协同迁移，每个迁移任务的ID记录在任务ID列表中，只有当一个时间分组内所有的子读任务迁移完成，才会开始下一个时间分组的迁移工作。
写入端收到子读任务转发的数据后，使用多值数据写入方式将数据写入到时序引擎。
注意事项
如果应用部署在ECS实例，建议Lindorm实例、ECS实例和TSDB实例使用相同的专有网络，以保证网络的连通性。
如果您使用公网将TSDB迁移至Lindorm时序引擎，请确保Lindorm实例和TSDB实例已开通外网地址，并将客户端IP地址添加至Lindorm实例和TSDB实例的白名单中，添加方法请参见设置白名单。
由于迁移过程中会读取TSDB的数据并将数据写入时序引擎，所以迁移前请评估以下内容在迁移过程中对当前业务是否有影响。
TSDB规格
应用部署的规格（例如ECS规格）
时间线数量
数据总量
平均每条时间线数据的上报频率
需要迁移的数据总时间范围
每个迁移作业切分周期的间隔时间
说明性能评估请参见性能测试。
由于多值数据写入方式不能直接通过SQL查询，如果需要使用SQL查询，请先创建时序数据表再进行数据迁移。
在时序引擎中默认使用13位Unix时间戳（单位为毫秒），TSDB中使用10位时间戳（单位为秒），迁移后TSDB的时间戳会自动设置为13位Unix时间戳（单位为毫秒）。
由于在时序引擎中不推荐使用单值数据写入方式，采用多值数据写入方式。如果之前写入TSDB的数据是通过单值写入方式那么迁移后在时序引擎中需要使用多值数据查询方式。示例如下：
//在TSDB中查询的语句 curl -u username:password ts-xxxxx:3242/api/query -XPOST -d '{ "start": 1657004460, "queries": [ { "aggregator": "none", "metric": "test_metric" } ] }' //在TSDB中查询的结果 [ { "aggregateTags": [], "dps": { "1657004460": 1.0 }, "fieldName": "", "metric": "test_metric", "tags": { "tagkey1": "1" } } ] //在时序引擎中查询的语句 curl -u username:password ld-xxxxx:8242/api/mquery -XPOST -d '{ "start":1657004460, "queries": [ { "metric": "test_metric", "fields": [ { "field": "*", "aggregator": "none" } ], "aggregator": "none" } ] }' //在时序引擎中查询的结果 [ { "aggregatedTags": [], "columns": [ "timestamp", "value" ], "metric": "test_metric", "tags": { "tagkey1": "1" }, "values": [ [ 1657004460000, 1.0 ] ] } ]
配置迁移任务
迁移任务的文件是将以下三部分参数由用户自定义并保存成JSON格式文件，例如：job.json文件。
设置任务参数。
参数
是否必选
描述
channel
否
任务的多线程并发度。默认值为1。
errorLimit
否
迁移过程中容忍的写入错误数。默认值为0。
设置读参数。具体参数值设置需要根据TSDB的实例规格来评估。
参数
是否必选
描述
sinkDbType
是
固定值为LINDORM-MIGRATION。
endpoint
是
TSDB实例的连接地址，查看方法请参见网络连接。
beginDateTime
是
指定迁移任务的开始时间。
endDateTime
是
指定迁移任务的结束时间。
splitIntervalMs
是
时间切分周期是根据总迁移时长和平均每条时间线上报频率设置的，例如604800000毫秒（周期为7天）。
如果平均每条时间线上报频率为秒级或者小于秒级，时间切分周期建议设置为一天内。
如果平均每条时间线上报频率为小时级，可以适量增加时间切分周期时长。
selfId
是
自定义迁移任务ID。
多进程并发迁移时每个迁移任务的ID不同，并将全部ID填写在jobIds中。
单进程迁移时迁移任务ID可以任意设置，并将迁移任务ID填写在jobIds中。
jobIds
是
迁移任务ID列表。
jobName
是
迁移任务名。对应任务状态表后缀，多进程并发时每个迁移任务的迁移任务名必须相同。
oidPath
是
全量时间线的存放地址。
oidBatch
是
每个子读任务每次读取的时间线数量。
oidCache
是
是否将迁移任务使用的时间线保存到内存。如果时间线数量为千万级，那么内存可能无法缓存所有时间线。
metrics
否
指定迁移的表。无默认值。例如：
["METRIC_1","METRIC_2"...]。说明迁移任务中每次读取的数据量由splitIntervalMs、oidBatch和平均每条时间线上报频率共同决定的。例如：splitIntervalMs为604800000毫秒，oidBatch为100条，平均每条时间线一小时上报一个点，则迁移任务中每次读取的数据量大约为100条×604800000毫秒÷3600000=16800条数据。
设置写参数。
参数
是否必选
描述
endpoint
是
时序引擎的连接地址，获取方法请参见查看连接地址。
batchSize
是
每次发送到时序引擎的最大数据点数。
multiField
是
使用多值数据写入方式将数据写入到时序引擎，固定值为true。
示例：job.json文件内容如下。
{
"job": {
"setting": {
"speed": {
"channel": 1
},
"errorLimit": {
"record": 0,
"percentage": 0.00
}
},
"content": [
{
"reader": {
"name": "tsdbreader",
"parameter": {
"sinkDbType": "LINDORM-MIGRATION",
"endpoint": "ts-xxxx:3242",
"beginDateTime": "2022-5-2 00:00:00",
"endDateTime": "2022-7-2 00:00:00",
"splitIntervalMs": 86400000,
"jobName":"myjob",
"selfId":1,
"jobIds":[1],
"oidPath":"{$myworkplace}/oidfile",
"oidBatch":100,
"oidCache":true
}
},
"writer": {
"name": "tsdbwriter",
"parameter": {
"endpoint": "ld-xxxx:8242",
"multiField":true,
"batchSize":500
}
}
}
]
}
}
启动迁移任务
下载时序数据迁移工具。
执行以下命令解压时序数据迁移工具。
tar -zxvf tsdb2lindorm.tar.gz执行以下命令启动迁移任务。
python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" job.json > job.result说明启动迁移任务命令中的
job需要替换为用户自定义的迁移任务文件名称。执行完成后，查看job.result中是否有报错，如果没有报错说明迁移任务执行成功。
可选：如果迁移中失败，可以使用多值查询语句查询TSDB的任务状态表，查询语句如下：
curl -u username:password ts-****:3242/api/mquery -XPOST -d '{ "start": 1, "queries": [ { "metric": "internal_datax_jobjobName", "fields": [ { "field": "*", "aggregator": "none" } ] } ] }'说明username:password：需要替换为TSDB实例的账号和密码，创建方法请参见用户管理。ts-****：需要替换为TSDB实例ID。jobName需要替换为用户自定义的迁移任务名，例如：internal_datax_jobmyjob。
查询的任务状态表结果如下。
Timestamp (endtime)
jobId (Tag)
state(field)
1651795199999 (2022-05-05 23:59:59.999)
3
ok
1651795199999 (2022-05-05 23:59:59.999)
2
ok
1651795199999 (2022-05-05 23:59:59.999)
1
ok
1651881599999 (2022-05-06 23:59:59.999)
2
ok
为了避免已迁移的任务再次执行，需要修改job.json文件中迁移任务的开始时间beginDateTime并重新启动任务。由任务状态表可知将beginDateTime设置为2022-05-06 00:00:00。
性能测试
迁移前需要评估TSDB实例的性能，TSDB基础版实例和标准版实例的性能测试数据请参考以下示例。
TSDB基础版 II（规格为4核 8 GB，数量为2个），测试项和数据如下表：
测试次数
数据量
任务进程数
配置
时间线文件大小
每秒迁移的数据点数
迁移用时
TSDB资源消耗
1
总时间线数据为3万
总数据点数为86400000
1
channel:2
oidCache:true
oidBatch:100
splitInterval:6h
mem:-Xms6G -Xmx6G
1.5 MB
230000
12分钟30秒
CPU占比为30%
2
总时间线数据为600万
总数据点数为2592000000
1
channel:10
oidCache:true
oidBatch:100
splitInterval:6h
mem:-Xms8G -Xmx8G
292 MB
200000
2小时55分钟30秒
CPU占比为70%~90%
3
总时间线数据为3000万
总数据点数为4320000000
1
channel:10
oidCache:false
oidBatch:100
splitInterval:6h
mem:-Xms28G -Xmx28G
1.5 GB
140000
9小时
CPU占比为40%~80%
4
总时间线数据为3000万
总数据点数为4320000000
3
channel:10
oidCache:false
oidBatch:100
splitInterval:6h
mem:-Xms8G -Xmx8G
1.5 GB
250000
5小时
CPU占比为90%
TSDB标准版 I（规格为8核 16 GB，数量为2个），测试项和数据如下表：
数据量
任务进程数
配置
时间线文件大小
每秒迁移的数据点数
迁移用时
资源消耗
总时间线数据为4000万
总数据点数为5760000000
3
channel:10
oidCache:false
oidBatch:100
splitInterval:6h
mem:-Xms8G -Xmx8G
2 GB
150000~200000
9小时
CPU占比为10%~20%