本文介紹時間序列資料庫（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%