六月婷婷AV,国产偷窥猎奇福利二区,日韩三级片。,好吊色网站,日韩成人中文在线视频,国产亚洲午夜啪啪,亚洲欧美另类国产精品,国产成人av1,任你艹在线观看

壓縮解壓 vs 加密解密，誰在吃掉 CPU？

在當(dāng)今大數(shù)據(jù)時(shí)代，時(shí)序數(shù)據(jù)庫的應(yīng)用越來越廣泛，尤其是在物聯(lián)網(wǎng)、工業(yè)監(jiān)控、金融分析等領(lǐng)域。TDengine 作為一款高性能的時(shí)序數(shù)據(jù)庫，憑借獨(dú)特的存儲(chǔ)架構(gòu)和高效的壓縮算法，在存儲(chǔ)和查詢效率上表現(xiàn)出色。然而，隨著數(shù)據(jù)規(guī)模的不斷增長，在保證數(shù)據(jù)安全性和存儲(chǔ)效率的同時(shí)，如何優(yōu)化 CPU 的資源占用，成為了一個(gè)值得深入討論的問題。

本文將探討 TDengine 在數(shù)據(jù)寫入與查詢場(chǎng)景下的壓縮解壓與加密解密過程中對(duì) CPU 資源的占用情況。通過深入分析 TDengine 的存儲(chǔ)壓縮技術(shù)和數(shù)據(jù)加密功能，我們將評(píng)估其在實(shí)際應(yīng)用中的性能表現(xiàn)及對(duì)系統(tǒng)資源的影響。希望本篇分析能為 TDengine 用戶提供有價(jià)值的參考，幫助大家在實(shí)際應(yīng)用中更好地權(quán)衡數(shù)據(jù)安全、存儲(chǔ)效率與系統(tǒng)性能。

測(cè)試環(huán)境

系統(tǒng)：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

測(cè)試準(zhǔn)備

建庫時(shí)指定加密方式，taosbenchmark 不支持加密建庫。

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"]}
                    ]
                }
            ]
        }
    ]
}

測(cè)試結(jié)果

場(chǎng)景一：sm4 加密 & lz4 壓縮

測(cè)試方法：使用 taosBenchmark 對(duì)上面的 json 文件進(jìn)行數(shù)據(jù)導(dǎo)入，同時(shí)對(duì) taosd 使用 perf 采樣，以下是火焰圖信息。

測(cè)試結(jié)果：

壓縮解壓 vs 加密解密，誰在吃掉 CPU？ - TDengine Database 時(shí)序數(shù)據(jù)庫

壓縮：LZ4compress：0.76% + 2.84%（table data compress）+0.1%（Stt）

解密：SM4_decrypt：5.87%（MergeFile）+ 1.12%（MergeFile）

加密：SM4_encrypt：59.02%（WAL） + 10.68%（table data） + 6.97%（table data end） + 2.04%（Stt）

結(jié)論：加密比壓縮占用更多 CPU 資源，大約達(dá) 70%。這是因?yàn)閴嚎s/解壓僅在數(shù)據(jù)生成時(shí)調(diào)用，而寫入 WAL、Meta 數(shù)據(jù)和落盤至 TSDB 的全過程都涉及加密。此外，系統(tǒng)啟動(dòng)時(shí)，讀取仍存于 WAL 中的未落盤數(shù)據(jù)、首次從 TSDB 讀取的數(shù)據(jù)，以及首次訪問 Meta 數(shù)據(jù)時(shí)，均需執(zhí)行解密操作。

場(chǎng)景二：lz4 壓縮解壓縮

測(cè)試方法：使用 Benchmark taosc 導(dǎo)入數(shù)據(jù)，在使用腳本對(duì)所有子表做一遍查詢，對(duì)查詢過程打火焰圖分析。

  for (int i = 0; i < 10000; i++) {
    sprintf(sql, "select * from d_%d", i);
    do_query(taos, sql);
  }

測(cè)試結(jié)果：

壓縮解壓 vs 加密解密，誰在吃掉 CPU？ - TDengine Database 時(shí)序數(shù)據(jù)庫

壓縮：compressData：3.33%（table data）+1.01%（table data end）

解壓縮：ColDataDecompress/decompressData：1.31%+0.66%+0.22%+0.18%

結(jié)論：加密解密的性能占比不高，大部分耗時(shí)在 LRU 緩存切換上，因?yàn)椴樵兇螖?shù)過多，導(dǎo)致測(cè)試不理想。

場(chǎng)景三：增大數(shù)據(jù)量，減少查詢次數(shù)，測(cè) lz4 壓縮解壓縮

測(cè)試方法：使用 Benchmark taosc 導(dǎo)入 10000 子表，1000 row 數(shù)據(jù)，查超級(jí)表（只查一次）

select * from meters；

測(cè)試結(jié)果：

壓縮解壓 vs 加密解密，誰在吃掉 CPU？ - TDengine Database 時(shí)序數(shù)據(jù)庫

壓縮：4.93%（table data end）+7.3%（table data）+0.44%（table data end）

解壓縮：0.95%+0.51%

結(jié)論：測(cè)試結(jié)果顯示，在正常情況下，壓縮/解壓過程占整個(gè)查詢的 CPU 開銷約 15%。由于壓縮/解壓僅在數(shù)據(jù)生成時(shí)調(diào)用，并且數(shù)據(jù)以塊形式進(jìn)行處理，其效率遠(yuǎn)高于加密/解密。

結(jié)論

通過分析 TDengine 在數(shù)據(jù)寫入與查詢場(chǎng)景下的壓縮解壓與加密解密過程的 CPU 占用情況，可以看出，加密對(duì)數(shù)據(jù)導(dǎo)入影響較大，占用約 77% 的 CPU 資源。寫入 WAL、Meta 數(shù)據(jù)及落盤至 TSDB 的全過程均涉及加密，而系統(tǒng)啟動(dòng)時(shí)，讀取仍存于 WAL 中的未落盤數(shù)據(jù)、首次從 TSDB 讀取的數(shù)據(jù)以及首次訪問 Meta 數(shù)據(jù)時(shí)，則需要執(zhí)行解密操作。相比之下，壓縮/解壓對(duì)數(shù)據(jù)導(dǎo)入導(dǎo)出的影響較小，僅占 CPU 資源約 15%。這是因?yàn)閴嚎s/解壓僅在數(shù)據(jù)生成時(shí)調(diào)用，并且數(shù)據(jù)以塊形式處理，其效率遠(yuǎn)高于加密/解密。

由此可見，TDengine 不僅顯著提高了存儲(chǔ)效率和數(shù)據(jù)安全性，還在一定程度上優(yōu)化了 CPU 的資源占用。尤其是在處理平穩(wěn)變化的時(shí)序數(shù)據(jù)時(shí)，TDengine 的差值編碼和通用壓縮技術(shù)表現(xiàn)出了極高的壓縮率，為用戶節(jié)約了大量的存儲(chǔ)成本。

然而，隨著數(shù)據(jù)規(guī)模的不斷增長，如何在保證數(shù)據(jù)安全性和存儲(chǔ)效率的同時(shí)，進(jìn)一步優(yōu)化 CPU 的資源占用，仍然是一個(gè)需要持續(xù)關(guān)注的問題。未來，隨著硬件性能的提升和算法的不斷優(yōu)化，我們有理由相信，TDengine 將在時(shí)序數(shù)據(jù)庫領(lǐng)域繼續(xù)發(fā)揮其優(yōu)勢(shì)，為用戶提供更加高效、安全的數(shù)據(jù)存儲(chǔ)和查詢解決方案。

希望本文的分析能夠?yàn)槭褂?TDengine 的用戶提供一些有價(jià)值的參考，幫助大家在實(shí)際應(yīng)用中更好地平衡數(shù)據(jù)安全、存儲(chǔ)效率與系統(tǒng)性能。如果您對(duì) TDengine 的壓縮和加密技術(shù)有更多的疑問或建議，歡迎在評(píng)論區(qū)留言討論。