據(jù)模型設計改造)
文章目錄每日一句正能量一、前言模型改造是遷移的核心二、模型差異分析2.1 InfluxDB模型特點2.2 KaiwuDB模型特點2.3 模型對比三、表結構設計3.1 單表設計3.2 多表設計3.3 分區(qū)表設計四、標簽設計優(yōu)化4.1 主標簽設計4.2 普通標簽設計4.3 字段列設計五、模型改造實戰(zhàn)5.1 改造前分析5.2 改造方案5.3 改造后優(yōu)勢六、性能優(yōu)化6.1 索引優(yōu)化6.2 分區(qū)優(yōu)化6.3 查詢優(yōu)化七、常見問題7.1 高基數(shù)問題7.2 數(shù)據(jù)類型問題7.3 時間精度問題八、總結每日一句正能量你走的每一步都算數(shù)即使現(xiàn)在看不見回報時間會在未來的某個轉角給你驚喜。所有經歷都有價值回報可能延遲但一定會以某種形式出現(xiàn)。你讀的書、熬的夜、練習的技能都在默默為那個“轉角驚喜”編織底色。一、前言模型改造是遷移的核心前面十四篇文章我分享了MySQL和InfluxDB遷移KaiwuDB的完整經驗。有讀者問“遷移完成后發(fā)現(xiàn)原有的模型設計在KaiwuDB上并不合適查詢性能不理想怎么辦”這是個好問題。InfluxDB和KaiwuDB雖然都是時序數(shù)據(jù)庫但數(shù)據(jù)模型設計理念不同。InfluxDB的tag/field模型靈活但查詢受限KaiwuDB的主標簽/普通標簽/字段列模型更規(guī)范但需要合理設計。本文就把InfluxDB到KaiwuDB時序數(shù)據(jù)模型設計改造的完整經驗分享出來包括模型差異分析、表結構設計、標簽設計優(yōu)化。二、模型差異分析2.1 InfluxDB模型特點InfluxDB采用measurement tag field模型Measurement: sensor_data Tags: device_id, location, status Fields: temperature, humidity, pressure Time: timestamp特點靈活tag和field可以動態(tài)添加自動索引tag自動創(chuàng)建索引無模式不需要預先定義表結構高寫入適合高頻寫入場景問題高基數(shù)tag值過多導致性能下降查詢受限不支持復雜SQL查詢數(shù)據(jù)膨脹tag變化導致數(shù)據(jù)冗余2.2 KaiwuDB模型特點KaiwuDB時序引擎采用主標簽 普通標簽 字段列模型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);特點規(guī)范需要預先定義表結構強類型字段類型明確SQL支持支持標準SQL查詢可擴展支持水平擴展優(yōu)勢查詢靈活支持復雜SQL查詢性能穩(wěn)定不會因為高基數(shù)導致性能下降數(shù)據(jù)一致強類型保證數(shù)據(jù)一致性2.3 模型對比維度InfluxDBKaiwuDB說明數(shù)據(jù)模型measurement tag field主標簽 普通標簽 字段列概念對應模式定義無模式強模式KaiwuDB需要預先定義索引tag自動索引主標簽自動索引都需要設計標簽查詢語言InfluxQLSQLKaiwuDB更標準高基數(shù)性能下降性能穩(wěn)定KaiwuDB更優(yōu)擴展性垂直擴展水平擴展KaiwuDB更優(yōu)三、表結構設計3.1 單表設計InfluxDB單表Measurement: sensor_data Tags: device_id, location Fields: temperature, humidityKaiwuDB單表CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽temperatureFLOAT,-- 字段列humidityFLOAT-- 字段列);3.2 多表設計InfluxDB多表Measurement: temperature_data Tags: device_id, location Fields: temperature Measurement: humidity_data Tags: device_id, location Fields: humidityKaiwuDB多表-- 溫度表CREATETABLEtemperature_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽temperatureFLOAT-- 字段列);-- 濕度表CREATETABLEhumidity_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽humidityFLOAT-- 字段列);3.3 分區(qū)表設計InfluxDB分區(qū)InfluxDB自動按時間分區(qū)不需要手動設計。KaiwuDB分區(qū)-- 按時間分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);CREATETABLEsensor_data_2023_q2PARTITIONOFsensor_dataFORVALUESFROM(2023-04-01)TO(2023-07-01);CREATETABLEsensor_data_2023_q3PARTITIONOFsensor_dataFORVALUESFROM(2023-07-01)TO(2023-10-01);CREATETABLEsensor_data_2023_q4PARTITIONOFsensor_dataFORVALUESFROM(2023-10-01)TO(2024-01-01);四、標簽設計優(yōu)化4.1 主標簽設計主標簽選擇原則高選擇性值分布均勻避免熱點穩(wěn)定性值不會頻繁變化查詢常用經常用于WHERE條件InfluxDB tagtags: device_id, location, statusKaiwuDB主標簽-- device_id作為主標簽CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,humidityFLOAT);4.2 普通標簽設計普通標簽選擇原則輔助查詢用于過濾和分組低基數(shù)值數(shù)量不會太多可變性值可以變化InfluxDB tagtags: device_id, location, statusKaiwuDB普通標簽-- location和status作為普通標簽CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,humidityFLOAT);4.3 字段列設計字段列選擇原則數(shù)值型溫度、濕度、壓力等變化頻繁值會隨時間變化聚合需求需要計算平均值、最大值等InfluxDB fieldfields: temperature, humidity, pressureKaiwuDB字段列-- temperature, humidity, pressure作為字段列CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);五、模型改造實戰(zhàn)5.1 改造前分析InfluxDB模型Measurement: sensor_data Tags: device_id, location, status, firmware_version Fields: temperature, humidity, pressure, voltage, current問題分析高基數(shù)firmware_version值變化頻繁導致高基數(shù)數(shù)據(jù)膨脹tag變化導致數(shù)據(jù)冗余查詢受限不支持復雜SQL查詢5.2 改造方案KaiwuDB模型-- 主表設備基本信息CREATETABLEdevice_info(device_id STRINGPRIMARYKEY,location STRING,statusSTRING,firmware_version STRING,created_atTIMESTAMP);-- 時序表傳感器數(shù)據(jù)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT,-- 字段列voltageFLOAT,-- 字段列currentFLOAT-- 字段列);-- 時序表設備狀態(tài)CREATETABLEdevice_status(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽statusSTRING,-- 普通標簽firmware_version STRING-- 普通標簽);5.3 改造后優(yōu)勢優(yōu)勢1降低高基數(shù)-- 改造前firmware_version作為tag導致高基數(shù)-- 改造后firmware_version作為普通標簽降低高基數(shù)-- 查詢設備信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;-- 查詢傳感器數(shù)據(jù)SELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;優(yōu)勢2支持復雜查詢-- 改造前InfluxQL不支持JOIN-- 改造后SQL支持JOIN-- 查詢設備最新狀態(tài)和傳感器數(shù)據(jù)SELECTd.device_id,d.location,d.status,s.temperature,s.humidity,s.pressureFROMdevice_info dJOINsensor_data sONd.device_ids.device_idWHEREs.timenow()-INTERVAL1 hourORDERBYs.timeDESC;優(yōu)勢3數(shù)據(jù)一致性-- 改造前tag變化導致數(shù)據(jù)冗余-- 改造后強類型保證數(shù)據(jù)一致性-- 更新設備信息UPDATEdevice_infoSETfirmware_versionv2.0WHEREdevice_iddevice_001;-- 查詢設備信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;六、性能優(yōu)化6.1 索引優(yōu)化-- 創(chuàng)建主標簽索引自動創(chuàng)建-- device_id已經是主標簽自動索引-- 創(chuàng)建普通標簽索引CREATEINDEXidx_locationONsensor_data(location);CREATEINDEXidx_statusONdevice_status(status);-- 創(chuàng)建時間索引自動創(chuàng)建-- time已經是主鍵的一部分自動索引6.2 分區(qū)優(yōu)化-- 按時間分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);6.3 查詢優(yōu)化-- 使用索引查詢EXPLAINANALYZESELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;-- 使用分區(qū)查詢EXPLAINANALYZESELECT*FROMsensor_data_2023_q1WHEREdevice_iddevice_001;七、常見問題7.1 高基數(shù)問題問題device_id數(shù)量過多導致主標簽高基數(shù)解決方案-- 使用哈希分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYHASH(device_id);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_p0PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER0);CREATETABLEsensor_data_p1PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER1);CREATETABLEsensor_data_p2PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER2);CREATETABLEsensor_data_p3PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER3);7.2 數(shù)據(jù)類型問題問題InfluxDB的float類型在KaiwuDB中映射為DOUBLE解決方案-- 明確指定類型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,-- 明確使用FLOAThumidityFLOAT);7.3 時間精度問題問題InfluxDB默認使用納秒精度KaiwuDB默認使用微秒精度解決方案-- 使用TIMESTAMPTZ保留時區(qū)信息CREATETABLEsensor_data(timeTIMESTAMPTZNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT);八、總結InfluxDB到KaiwuDB時序數(shù)據(jù)模型設計改造是遷移成功的關鍵。核心改造點主標簽設計選擇高選擇性、穩(wěn)定性、查詢常用的字段普通標簽設計選擇輔助查詢、低基數(shù)、可變性的字段字段列設計選擇數(shù)值型、變化頻繁、有聚合需求的字段表結構設計合理分區(qū)降低高基數(shù)影響關鍵經驗理解模型差異InfluxDB和KaiwuDB的數(shù)據(jù)模型不同合理設計標簽主標簽和普通標簽的選擇很重要處理數(shù)據(jù)類型注意類型映射和精度問題優(yōu)化查詢性能利用KaiwuDB的SQL優(yōu)勢做好數(shù)據(jù)校驗確保數(shù)據(jù)一致性如果你正在考慮InfluxDB遷移KaiwuDB建議先做好模型設計確保遷移后性能滿足業(yè)務需求。轉載自https://blog.csdn.net/u014727709/article/details/164125627歡迎 點贊?評論?收藏歡迎指正 InfluxDB→KaiwuDB時序數(shù)據(jù)模型設計改造
文章目錄每日一句正能量一、前言模型改造是遷移的核心二、模型差異分析2.1 InfluxDB模型特點2.2 KaiwuDB模型特點2.3 模型對比三、表結構設計3.1 單表設計3.2 多表設計3.3 分區(qū)表設計四、標簽設計優(yōu)化4.1 主標簽設計4.2 普通標簽設計4.3 字段列設計五、模型改造實戰(zhàn)5.1 改造前分析5.2 改造方案5.3 改造后優(yōu)勢六、性能優(yōu)化6.1 索引優(yōu)化6.2 分區(qū)優(yōu)化6.3 查詢優(yōu)化七、常見問題7.1 高基數(shù)問題7.2 數(shù)據(jù)類型問題7.3 時間精度問題八、總結每日一句正能量你走的每一步都算數(shù)即使現(xiàn)在看不見回報時間會在未來的某個轉角給你驚喜。所有經歷都有價值回報可能延遲但一定會以某種形式出現(xiàn)。你讀的書、熬的夜、練習的技能都在默默為那個“轉角驚喜”編織底色。一、前言模型改造是遷移的核心前面十四篇文章我分享了MySQL和InfluxDB遷移KaiwuDB的完整經驗。有讀者問“遷移完成后發(fā)現(xiàn)原有的模型設計在KaiwuDB上并不合適查詢性能不理想怎么辦”這是個好問題。InfluxDB和KaiwuDB雖然都是時序數(shù)據(jù)庫但數(shù)據(jù)模型設計理念不同。InfluxDB的tag/field模型靈活但查詢受限KaiwuDB的主標簽/普通標簽/字段列模型更規(guī)范但需要合理設計。本文就把InfluxDB到KaiwuDB時序數(shù)據(jù)模型設計改造的完整經驗分享出來包括模型差異分析、表結構設計、標簽設計優(yōu)化。二、模型差異分析2.1 InfluxDB模型特點InfluxDB采用measurement tag field模型Measurement: sensor_data Tags: device_id, location, status Fields: temperature, humidity, pressure Time: timestamp特點靈活tag和field可以動態(tài)添加自動索引tag自動創(chuàng)建索引無模式不需要預先定義表結構高寫入適合高頻寫入場景問題高基數(shù)tag值過多導致性能下降查詢受限不支持復雜SQL查詢數(shù)據(jù)膨脹tag變化導致數(shù)據(jù)冗余2.2 KaiwuDB模型特點KaiwuDB時序引擎采用主標簽 普通標簽 字段列模型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);特點規(guī)范需要預先定義表結構強類型字段類型明確SQL支持支持標準SQL查詢可擴展支持水平擴展優(yōu)勢查詢靈活支持復雜SQL查詢性能穩(wěn)定不會因為高基數(shù)導致性能下降數(shù)據(jù)一致強類型保證數(shù)據(jù)一致性2.3 模型對比維度InfluxDBKaiwuDB說明數(shù)據(jù)模型measurement tag field主標簽 普通標簽 字段列概念對應模式定義無模式強模式KaiwuDB需要預先定義索引tag自動索引主標簽自動索引都需要設計標簽查詢語言InfluxQLSQLKaiwuDB更標準高基數(shù)性能下降性能穩(wěn)定KaiwuDB更優(yōu)擴展性垂直擴展水平擴展KaiwuDB更優(yōu)三、表結構設計3.1 單表設計InfluxDB單表Measurement: sensor_data Tags: device_id, location Fields: temperature, humidityKaiwuDB單表CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽temperatureFLOAT,-- 字段列humidityFLOAT-- 字段列);3.2 多表設計InfluxDB多表Measurement: temperature_data Tags: device_id, location Fields: temperature Measurement: humidity_data Tags: device_id, location Fields: humidityKaiwuDB多表-- 溫度表CREATETABLEtemperature_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽temperatureFLOAT-- 字段列);-- 濕度表CREATETABLEhumidity_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽humidityFLOAT-- 字段列);3.3 分區(qū)表設計InfluxDB分區(qū)InfluxDB自動按時間分區(qū)不需要手動設計。KaiwuDB分區(qū)-- 按時間分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);CREATETABLEsensor_data_2023_q2PARTITIONOFsensor_dataFORVALUESFROM(2023-04-01)TO(2023-07-01);CREATETABLEsensor_data_2023_q3PARTITIONOFsensor_dataFORVALUESFROM(2023-07-01)TO(2023-10-01);CREATETABLEsensor_data_2023_q4PARTITIONOFsensor_dataFORVALUESFROM(2023-10-01)TO(2024-01-01);四、標簽設計優(yōu)化4.1 主標簽設計主標簽選擇原則高選擇性值分布均勻避免熱點穩(wěn)定性值不會頻繁變化查詢常用經常用于WHERE條件InfluxDB tagtags: device_id, location, statusKaiwuDB主標簽-- device_id作為主標簽CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,humidityFLOAT);4.2 普通標簽設計普通標簽選擇原則輔助查詢用于過濾和分組低基數(shù)值數(shù)量不會太多可變性值可以變化InfluxDB tagtags: device_id, location, statusKaiwuDB普通標簽-- location和status作為普通標簽CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽location STRING,-- 普通標簽statusSTRING,-- 普通標簽temperatureFLOAT,humidityFLOAT);4.3 字段列設計字段列選擇原則數(shù)值型溫度、濕度、壓力等變化頻繁值會隨時間變化聚合需求需要計算平均值、最大值等InfluxDB fieldfields: temperature, humidity, pressureKaiwuDB字段列-- temperature, humidity, pressure作為字段列CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);五、模型改造實戰(zhàn)5.1 改造前分析InfluxDB模型Measurement: sensor_data Tags: device_id, location, status, firmware_version Fields: temperature, humidity, pressure, voltage, current問題分析高基數(shù)firmware_version值變化頻繁導致高基數(shù)數(shù)據(jù)膨脹tag變化導致數(shù)據(jù)冗余查詢受限不支持復雜SQL查詢5.2 改造方案KaiwuDB模型-- 主表設備基本信息CREATETABLEdevice_info(device_id STRINGPRIMARYKEY,location STRING,statusSTRING,firmware_version STRING,created_atTIMESTAMP);-- 時序表傳感器數(shù)據(jù)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT,-- 字段列voltageFLOAT,-- 字段列currentFLOAT-- 字段列);-- 時序表設備狀態(tài)CREATETABLEdevice_status(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主標簽statusSTRING,-- 普通標簽firmware_version STRING-- 普通標簽);5.3 改造后優(yōu)勢優(yōu)勢1降低高基數(shù)-- 改造前firmware_version作為tag導致高基數(shù)-- 改造后firmware_version作為普通標簽降低高基數(shù)-- 查詢設備信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;-- 查詢傳感器數(shù)據(jù)SELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;優(yōu)勢2支持復雜查詢-- 改造前InfluxQL不支持JOIN-- 改造后SQL支持JOIN-- 查詢設備最新狀態(tài)和傳感器數(shù)據(jù)SELECTd.device_id,d.location,d.status,s.temperature,s.humidity,s.pressureFROMdevice_info dJOINsensor_data sONd.device_ids.device_idWHEREs.timenow()-INTERVAL1 hourORDERBYs.timeDESC;優(yōu)勢3數(shù)據(jù)一致性-- 改造前tag變化導致數(shù)據(jù)冗余-- 改造后強類型保證數(shù)據(jù)一致性-- 更新設備信息UPDATEdevice_infoSETfirmware_versionv2.0WHEREdevice_iddevice_001;-- 查詢設備信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;六、性能優(yōu)化6.1 索引優(yōu)化-- 創(chuàng)建主標簽索引自動創(chuàng)建-- device_id已經是主標簽自動索引-- 創(chuàng)建普通標簽索引CREATEINDEXidx_locationONsensor_data(location);CREATEINDEXidx_statusONdevice_status(status);-- 創(chuàng)建時間索引自動創(chuàng)建-- time已經是主鍵的一部分自動索引6.2 分區(qū)優(yōu)化-- 按時間分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);6.3 查詢優(yōu)化-- 使用索引查詢EXPLAINANALYZESELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;-- 使用分區(qū)查詢EXPLAINANALYZESELECT*FROMsensor_data_2023_q1WHEREdevice_iddevice_001;七、常見問題7.1 高基數(shù)問題問題device_id數(shù)量過多導致主標簽高基數(shù)解決方案-- 使用哈希分區(qū)CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYHASH(device_id);-- 創(chuàng)建分區(qū)CREATETABLEsensor_data_p0PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER0);CREATETABLEsensor_data_p1PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER1);CREATETABLEsensor_data_p2PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER2);CREATETABLEsensor_data_p3PARTITIONOFsensor_dataFORVALUESWITH(MODULUS4,REMAINDER3);7.2 數(shù)據(jù)類型問題問題InfluxDB的float類型在KaiwuDB中映射為DOUBLE解決方案-- 明確指定類型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,-- 明確使用FLOAThumidityFLOAT);7.3 時間精度問題問題InfluxDB默認使用納秒精度KaiwuDB默認使用微秒精度解決方案-- 使用TIMESTAMPTZ保留時區(qū)信息CREATETABLEsensor_data(timeTIMESTAMPTZNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT);八、總結InfluxDB到KaiwuDB時序數(shù)據(jù)模型設計改造是遷移成功的關鍵。核心改造點主標簽設計選擇高選擇性、穩(wěn)定性、查詢常用的字段普通標簽設計選擇輔助查詢、低基數(shù)、可變性的字段字段列設計選擇數(shù)值型、變化頻繁、有聚合需求的字段表結構設計合理分區(qū)降低高基數(shù)影響關鍵經驗理解模型差異InfluxDB和KaiwuDB的數(shù)據(jù)模型不同合理設計標簽主標簽和普通標簽的選擇很重要處理數(shù)據(jù)類型注意類型映射和精度問題優(yōu)化查詢性能利用KaiwuDB的SQL優(yōu)勢做好數(shù)據(jù)校驗確保數(shù)據(jù)一致性如果你正在考慮InfluxDB遷移KaiwuDB建議先做好模型設計確保遷移后性能滿足業(yè)務需求。轉載自https://blog.csdn.net/u014727709/article/details/164125627歡迎 點贊?評論?收藏歡迎指正