本文介紹時間序列數據庫（Time Series Database，簡稱TSDB）全量遷移至云原生多模數據庫 Lindorm時序引擎的方法。
前提條件
已安裝Linux或者macOS操作系統(tǒng)，并且安裝以下環(huán)境。
已安裝Java環(huán)境，版本為JDK 1.8及以上。
已安裝Python環(huán)境，版本為2.x或者3.x。
TSDB的版本為2.7.4及以上。
已創(chuàng)建云原生多模數據庫 Lindorm實例并開通時序引擎，請參見創(chuàng)建實例。
背景信息
時序引擎由阿里云自主研發(fā)，兼容了TSDB的大部分API。時序引擎相比TSDB具有高性能、低成本、多功能等優(yōu)勢。目前TSDB已停止售賣，建議您將TSDB的全量數據遷移至Lindorm時序引擎。
遷移流程
TSDB全量遷移至Lindorm時序引擎的遷移流程如下：
通過時序數據遷移工具讀取TSDB所有的時間線數據，并將數據保存至本地文件。
根據遷移任務配置（指定開始時間、結束時間和時間切分周期）將遷移任務劃分成多個時間分組。按照遷移任務配置中指定的oidBatch（即時間線數量）參數將每個時間分組再次劃分為多個子讀任務，每個子讀任務負責讀取多個時間線中指定時間范圍的數據。
每個子讀任務將讀取的數據轉發(fā)給寫入端，當一個時間分組內所有的子讀任務讀取完成后，記錄當前時間分組、遷移任務ID和任務狀態(tài)到任務狀態(tài)表中（表名的格式為：
internal_datax_jobjobName)。說明時序數據遷移工具支持多任務協同遷移，每個遷移任務的ID記錄在任務ID列表中，只有當一個時間分組內所有的子讀任務遷移完成，才會開始下一個時間分組的遷移工作。
寫入端收到子讀任務轉發(fā)的數據后，使用多值數據寫入方式將數據寫入到時序引擎。
注意事項
如果應用部署在ECS實例，建議Lindorm實例、ECS實例和TSDB實例使用相同的專有網絡，以保證網絡的連通性。
如果您使用公網將TSDB遷移至Lindorm時序引擎，請確保Lindorm實例和TSDB實例已開通外網地址，并將客戶端IP地址添加至Lindorm實例和TSDB實例的白名單中，添加方法請參見設置白名單。
由于遷移過程中會讀取TSDB的數據并將數據寫入時序引擎，所以遷移前請評估以下內容在遷移過程中對當前業(yè)務是否有影響。
TSDB規(guī)格
應用部署的規(guī)格（例如ECS規(guī)格）
時間線數量
數據總量
平均每條時間線數據的上報頻率
需要遷移的數據總時間范圍
每個遷移作業(yè)切分周期的間隔時間
說明性能評估請參見性能測試。
由于多值數據寫入方式不能直接通過SQL查詢，如果需要使用SQL查詢，請先創(chuàng)建時序數據表再進行數據遷移。
在時序引擎中默認使用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
否
任務的多線程并發(fā)度。默認值為1。
errorLimit
否
遷移過程中容忍的寫入錯誤數。默認值為0。
設置讀參數。具體參數值設置需要根據TSDB的實例規(guī)格來評估。
參數
是否必選
描述
sinkDbType
是
固定值為LINDORM-MIGRATION。
endpoint
是
TSDB實例的連接地址，查看方法請參見網絡連接。
beginDateTime
是
指定遷移任務的開始時間。
endDateTime
是
指定遷移任務的結束時間。
splitIntervalMs
是
時間切分周期是根據總遷移時長和平均每條時間線上報頻率設置的，例如604800000毫秒（周期為7天）。
如果平均每條時間線上報頻率為秒級或者小于秒級，時間切分周期建議設置為一天內。
如果平均每條時間線上報頻率為小時級，可以適量增加時間切分周期時長。
selfId
是
自定義遷移任務ID。
多進程并發(fā)遷移時每個遷移任務的ID不同，并將全部ID填寫在jobIds中。
單進程遷移時遷移任務ID可以任意設置，并將遷移任務ID填寫在jobIds中。
jobIds
是
遷移任務ID列表。
jobName
是
遷移任務名。對應任務狀態(tài)表后綴，多進程并發(fā)時每個遷移任務的遷移任務名必須相同。
oidPath
是
全量時間線的存放地址。
oidBatch
是
每個子讀任務每次讀取的時間線數量。
oidCache
是
是否將遷移任務使用的時間線保存到內存。如果時間線數量為千萬級，那么內存可能無法緩存所有時間線。
metrics
否
指定遷移的表。無默認值。例如：
["METRIC_1","METRIC_2"...]。說明遷移任務中每次讀取的數據量由splitIntervalMs、oidBatch和平均每條時間線上報頻率共同決定的。例如：splitIntervalMs為604800000毫秒，oidBatch為100條，平均每條時間線一小時上報一個點，則遷移任務中每次讀取的數據量大約為100條×604800000毫秒÷3600000=16800條數據。
設置寫參數。
參數
是否必選
描述
endpoint
是
時序引擎的連接地址，獲取方法請參見查看連接地址。
batchSize
是
每次發(fā)送到時序引擎的最大數據點數。
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
}
}
}
]
}
}
啟動遷移任務
下載時序數據遷移工具。
執(zhí)行以下命令解壓時序數據遷移工具。
tar -zxvf tsdb2lindorm.tar.gz執(zhí)行以下命令啟動遷移任務。
python datax/bin/datax.py --jvm="-Xms8G -Xmx8G" job.json > job.result說明啟動遷移任務命令中的
job需要替換為用戶自定義的遷移任務文件名稱。執(zhí)行完成后，查看job.result中是否有報錯，如果沒有報錯說明遷移任務執(zhí)行成功。
可選：如果遷移中失敗，可以使用多值查詢語句查詢TSDB的任務狀態(tài)表，查詢語句如下：
curl -u username:password ts-****:3242/api/mquery -XPOST -d '{ "start": 1, "queries": [ { "metric": "internal_datax_jobjobName", "fields": [ { "field": "*", "aggregator": "none" } ] } ] }'說明username:password：需要替換為TSDB實例的賬號和密碼，創(chuàng)建方法請參見用戶管理。ts-****：需要替換為TSDB實例ID。jobName需要替換為用戶自定義的遷移任務名，例如：internal_datax_jobmyjob。
查詢的任務狀態(tài)表結果如下。
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
為了避免已遷移的任務再次執(zhí)行，需要修改job.json文件中遷移任務的開始時間beginDateTime并重新啟動任務。由任務狀態(tài)表可知將beginDateTime設置為2022-05-06 00:00:00。
性能測試
遷移前需要評估TSDB實例的性能，TSDB基礎版實例和標準版實例的性能測試數據請參考以下示例。
TSDB基礎版 II（規(guī)格為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（規(guī)格為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%