在當今大數據時代，時序數據庫的應用越來越廣泛，尤其是在物聯網、工業監控、金融分析等領域。TDengine 作為一款高性能的時序數據庫，憑(ping)借(jie)獨特的(de)(de)存(cun)儲(chu)架構和(he)(he)高效的(de)(de)壓縮(suo)算法，在(zai)存(cun)儲(chu)和(he)(he)查詢效率上表現出色。然而，隨著數(shu)據規模的(de)(de)不(bu)斷增長，在(zai)保證數(shu)據安全性(xing)和(he)(he)存(cun)儲(chu)效率的(de)(de)同時(shi)，如(ru)何優(you)化 CPU 的(de)(de)資源占用(yong)，成為了一(yi)個值(zhi)得(de)深入(ru)討論的(de)(de)問題(ti)。
本文將探討 TDengine 在數據寫入與查詢場景下的壓縮解壓與加密解密過程中對 CPU 資源的占用情況。通過(guo)深入分析 TDengine 的(de)存(cun)儲壓縮(suo)技術(shu)和數(shu)(shu)據加(jia)密功(gong)能，我們(men)將評估其在實(shi)際應用(yong)中的(de)性(xing)能表現(xian)及對系統資源的(de)影響。希望(wang)本篇分析能為 TDengine 用(yong)戶提供有(you)價值的(de)參考，幫助大家在實(shi)際應用(yong)中更好(hao)地權衡數(shu)(shu)據安全、存(cun)儲效率(lv)與系統性(xing)能。
測試環境
系統：Darwin Kernel Version 23.6.0
taosd 版本：
TDengine Enterprise Edition
taosd version: 3.3.5.2.alpha compatible_version: 3.0.0.0
git: 0a42d321120b313019f0ee9b1d7e23599bfd462d
gitOfInternal: ab27dbaf76fa60c57363a3053c9c5b012fafddad
build: macOS-arm64 2025-01-22 15:59:30 +0800集群：1 dnodes, 1 vgroups, WAL_LEVEL 1
測試準備
建庫時指定(ding)加(jia)密(mi)(mi)方式(shi)，taosbenchmark 不支持加(jia)密(mi)(mi)建庫。
create database test ENCRYPT_ALGORITHM 'sm4';insert.json
{
"filetype": "insert",
"cfgdir": "/etc/taos",
"host": "localhost",
"port": 6030,
"user": "root",
"password": "taosdata",
"connection_pool_size": 8,
"num_of_records_per_req": 20000,
"thread_count": 8,
"create_table_thread_count": 10,
"result_file": "./insert_res_mix.txt",
"confirm_parameter_prompt": "no",
"insert_interval": 0,
"continue_if_fail": "yes",
"databases": [
{
"dbinfo": {
"name": "test",
"drop": "no",
"vgroups": 1,
"replica": 1,
"stt_trigger": 1,
"minRows": 100,
"WAL_RETENTION_PERIOD": 10,
"maxRows": 4096
},
"super_tables": [
{
"name": "meters",
"child_table_exists": "no",
"auto_create_table":"no",
"childtable_count": 10000,
"insert_rows": 100,
"childtable_prefix": "d",
"insert_mode": "stmt2",
"insert_interval": 0,
"timestamp_step": 900000,
"start_timestamp":"2022-09-01 10:00:00",
"disorder_ratio": 0,
"update_ratio": 0,
"delete_ratio": 0,
"continue_if_fail": "yes",
"disorder_fill_interval": 0,
"update_fill_interval": 0,
"generate_row_rule": 0,
"columns": [
{ "type": "binary","compress":"lz4", "name": "val", "len": 64},
{ "type": "binary","compress":"lz4", "name": "order_no", "len": 64},
{ "type": "binary","compress":"lz4", "name": "production_no", "len": 64},
{ "type": "binary","compress":"lz4", "name": "modal_no", "len": 64}
],
"tags": [
{ "type": "binary", "name": "device_no", "len": 64 ,"values": ["San Francisco", "Los Angles", "San Diego",
"San Jose", "Palo Alto", "Campbell", "Mountain View",
"Sunnyvale", "Santa Clara", "Cupertino"] },
{ "type": "int", "name": "channel_id", "max": 100, "min": 0},
{ "type": "binary", "name": "point_no", "len": 64 ,"values": ["San Francisco", "Los Angles", "San Diego",
"San Jose", "Palo Alto", "Campbell", "Mountain View",
"Sunnyvale", "Santa Clara", "Cupertino"]},
{ "type": "int", "name": "datatype", "max": 100, "min": 0},
{ "type": "int", "name": "business_type", "max": 100, "min": 0},
{ "type": "binary", "name": "unit", "len": 16 ,"values": ["San Francisco", "Los Angles", "San Diego",
"San Jose", "Palo Alto", "Campbell", "Mountain View",
"Sunnyvale", "Santa Clara", "Cupertino"]}
]
}
]
}
]
}測試結果
場景一：sm4 加密 & lz4 壓縮
測試方法：使用(yong) taosBenchmark 對上面(mian)的 json 文件進行數據導入，同(tong)時對 taosd 使用(yong) perf 采樣，以下是火(huo)焰圖信(xin)息。
測試結果：
壓縮：LZ4compress：0.76% + 2.84%（table data compress）+0.1%（Stt）
解密：SM4_decrypt：5.87%（MergeFile）+ 1.12%（MergeFile）
加密(mi)：SM4_encrypt：59.02%（WAL） + 10.68%（table data） + 6.97%（table data end） + 2.04%（Stt）
結論：加密比壓縮占用更多 CPU 資源，大約達 70%。這是因為壓縮/解壓僅在數據生成時調用，而寫入 WAL、Meta 數據和落盤至 TSDB 的全(quan)過(guo)程都涉(she)及加密。此外，系統啟(qi)動時，讀(du)取仍存于 WAL 中的未落盤數(shu)據、首(shou)次(ci)從 TSDB 讀(du)取的數(shu)據，以(yi)及首(shou)次(ci)訪問 Meta 數(shu)據時，均(jun)需(xu)執行(xing)解密操作。
場景二：lz4 壓縮解壓縮
測試方法：使用 Benchmark taosc 導入數據，在使用腳本對所(suo)有子(zi)表做一(yi)遍查(cha)詢，對查(cha)詢過程打火焰圖分析。
for (int i = 0; i < 10000; i++) {
sprintf(sql, "select * from d_%d", i);
do_query(taos, sql);
}測試結果：
壓縮：compressData：3.33%（table data）+1.01%（table data end）
解壓縮：ColDataDecompress/decompressData：1.31%+0.66%+0.22%+0.18%
結論：加密解(jie)密的性能占比不(bu)高，大(da)部分耗時在 LRU 緩存切換上，因為查詢(xun)次(ci)數過多(duo)，導致測試不(bu)理想。
場景三：增大數據量，減少查詢次數，測 lz4 壓縮解壓縮
測試方法：使用 Benchmark taosc 導入 10000 子表，1000 row 數據(ju)，查超級(ji)表（只查一次）
select * from meters；測試結果：
壓縮：4.93%（table data end）+7.3%（table data）+0.44%（table data end）
解壓縮：0.95%+0.51%
結論：測試結果顯示(shi)，在正常情況下，壓縮(suo)/解(jie)壓過程占整個查詢的 CPU 開銷約 15%。由于(yu)壓縮(suo)/解(jie)壓僅在數據生成時(shi)調用，并且數據以塊形式進行(xing)處理，其效率遠高于(yu)加密(mi)/解(jie)密(mi)。
結論
通(tong)過分析 TDengine 在數據(ju)(ju)寫入(ru)與查詢場景下的(de)(de)(de)壓(ya)縮(suo)(suo)解(jie)(jie)壓(ya)與加(jia)密解(jie)(jie)密過程的(de)(de)(de) CPU 占(zhan)用情(qing)況(kuang)，可以(yi)看出(chu)，加(jia)密對數據(ju)(ju)導(dao)(dao)入(ru)影響(xiang)較大，占(zhan)用約 77% 的(de)(de)(de) CPU 資源。寫入(ru) WAL、Meta 數據(ju)(ju)及落(luo)盤至 TSDB 的(de)(de)(de)全過程均涉及加(jia)密，而系統啟(qi)動時，讀取(qu)仍存于 WAL 中的(de)(de)(de)未落(luo)盤數據(ju)(ju)、首次(ci)從 TSDB 讀取(qu)的(de)(de)(de)數據(ju)(ju)以(yi)及首次(ci)訪問 Meta 數據(ju)(ju)時，則需要執行解(jie)(jie)密操作(zuo)。相比之下，壓(ya)縮(suo)(suo)/解(jie)(jie)壓(ya)對數據(ju)(ju)導(dao)(dao)入(ru)導(dao)(dao)出(chu)的(de)(de)(de)影響(xiang)較小，僅占(zhan) CPU 資源約 15%。這是(shi)因為(wei)壓(ya)縮(suo)(suo)/解(jie)(jie)壓(ya)僅在數據(ju)(ju)生成時調用，并(bing)且數據(ju)(ju)以(yi)塊(kuai)形式(shi)處理(li)，其效(xiao)率(lv)遠高于加(jia)密/解(jie)(jie)密。
由(you)此可見，TDengine 不僅顯著提(ti)高(gao)了存(cun)儲(chu)效率和數據安全(quan)性，還在一定程度上優(you)化了 CPU 的(de)(de)資(zi)源(yuan)占用(yong)。尤(you)其是在處理平穩變化的(de)(de)時序數據時，TDengine 的(de)(de)差值編(bian)碼(ma)和通用(yong)壓縮技術(shu)表(biao)現出了極高(gao)的(de)(de)壓縮率，為用(yong)戶(hu)節約了大量的(de)(de)存(cun)儲(chu)成本(ben)。
然而，隨著數(shu)(shu)據(ju)(ju)規模的不斷增(zeng)長，如(ru)何在保證數(shu)(shu)據(ju)(ju)安全(quan)性和(he)存儲效率的同(tong)時(shi)，進(jin)一步優化 CPU 的資源占用(yong)，仍然是一個需要持續(xu)關注(zhu)的問題。未來，隨著硬(ying)件性能的提(ti)升和(he)算法的不斷優化，我們有理由(you)相信，TDengine 將在時(shi)序數(shu)(shu)據(ju)(ju)庫(ku)領域繼續(xu)發揮其優勢，為用(yong)戶提(ti)供更加高效、安全(quan)的數(shu)(shu)據(ju)(ju)存儲和(he)查(cha)詢解決(jue)方(fang)案。
希望本(ben)文的(de)分析能(neng)夠為使用(yong) TDengine 的(de)用(yong)戶提供一些有(you)價值(zhi)的(de)參考，幫助大家在(zai)實際應用(yong)中(zhong)更(geng)好地平衡(heng)數據(ju)安全、存(cun)儲效率與系統性(xing)能(neng)。如果(guo)您對(dui) TDengine 的(de)壓縮和加密(mi)技術(shu)有(you)更(geng)多的(de)疑(yi)問或建議，歡迎在(zai)評論區留(liu)言討論。
