文章目录每日一句正能量一、前言模型改造是迁移的核心二、模型差异分析2.1 InfluxDB模型特点2.2 KaiwuDB模型特点2.3 模型对比三、表结构设计3.1 单表设计3.2 多表设计3.3 分区表设计四、标签设计优化4.1 主标签设计4.2 普通标签设计4.3 字段列设计五、模型改造实战5.1 改造前分析5.2 改造方案5.3 改造后优势六、性能优化6.1 索引优化6.2 分区优化6.3 查询优化七、常见问题7.1 高基数问题7.2 数据类型问题7.3 时间精度问题八、总结每日一句正能量你走的每一步都算数即使现在看不见回报时间会在未来的某个转角给你惊喜。所有经历都有价值回报可能延迟但一定会以某种形式出现。你读的书、熬的夜、练习的技能都在默默为那个“转角惊喜”编织底色。一、前言模型改造是迁移的核心前面十四篇文章我分享了MySQL和InfluxDB迁移KaiwuDB的完整经验。有读者问“迁移完成后发现原有的模型设计在KaiwuDB上并不合适查询性能不理想怎么办”这是个好问题。InfluxDB和KaiwuDB虽然都是时序数据库但数据模型设计理念不同。InfluxDB的tag/field模型灵活但查询受限KaiwuDB的主标签/普通标签/字段列模型更规范但需要合理设计。本文就把InfluxDB到KaiwuDB时序数据模型设计改造的完整经验分享出来包括模型差异分析、表结构设计、标签设计优化。二、模型差异分析2.1 InfluxDB模型特点InfluxDB采用measurement tag field模型Measurement: sensor_data Tags: device_id, location, status Fields: temperature, humidity, pressure Time: timestamp特点灵活tag和field可以动态添加自动索引tag自动创建索引无模式不需要预先定义表结构高写入适合高频写入场景问题高基数tag值过多导致性能下降查询受限不支持复杂SQL查询数据膨胀tag变化导致数据冗余2.2 KaiwuDB模型特点KaiwuDB时序引擎采用主标签 普通标签 字段列模型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);特点规范需要预先定义表结构强类型字段类型明确SQL支持支持标准SQL查询可扩展支持水平扩展优势查询灵活支持复杂SQL查询性能稳定不会因为高基数导致性能下降数据一致强类型保证数据一致性2.3 模型对比维度InfluxDBKaiwuDB说明数据模型measurement tag field主标签 普通标签 字段列概念对应模式定义无模式强模式KaiwuDB需要预先定义索引tag自动索引主标签自动索引都需要设计标签查询语言InfluxQLSQLKaiwuDB更标准高基数性能下降性能稳定KaiwuDB更优扩展性垂直扩展水平扩展KaiwuDB更优三、表结构设计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 分区表设计InfluxDB分区InfluxDB自动按时间分区不需要手动设计。KaiwuDB分区-- 按时间分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 创建分区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);四、标签设计优化4.1 主标签设计主标签选择原则高选择性值分布均匀避免热点稳定性值不会频繁变化查询常用经常用于WHERE条件InfluxDB tagtags: device_id, location, statusKaiwuDB主标签-- device_id作为主标签CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,humidityFLOAT);4.2 普通标签设计普通标签选择原则辅助查询用于过滤和分组低基数值数量不会太多可变性值可以变化InfluxDB tagtags: device_id, location, statusKaiwuDB普通标签-- location和status作为普通标签CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,humidityFLOAT);4.3 字段列设计字段列选择原则数值型温度、湿度、压力等变化频繁值会随时间变化聚合需求需要计算平均值、最大值等InfluxDB fieldfields: temperature, humidity, pressureKaiwuDB字段列-- temperature, humidity, pressure作为字段列CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);五、模型改造实战5.1 改造前分析InfluxDB模型Measurement: sensor_data Tags: device_id, location, status, firmware_version Fields: temperature, humidity, pressure, voltage, current问题分析高基数firmware_version值变化频繁导致高基数数据膨胀tag变化导致数据冗余查询受限不支持复杂SQL查询5.2 改造方案KaiwuDB模型-- 主表设备基本信息CREATETABLEdevice_info(device_id STRINGPRIMARYKEY,location STRING,statusSTRING,firmware_version STRING,created_atTIMESTAMP);-- 时序表传感器数据CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT,-- 字段列voltageFLOAT,-- 字段列currentFLOAT-- 字段列);-- 时序表设备状态CREATETABLEdevice_status(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签statusSTRING,-- 普通标签firmware_version STRING-- 普通标签);5.3 改造后优势优势1降低高基数-- 改造前firmware_version作为tag导致高基数-- 改造后firmware_version作为普通标签降低高基数-- 查询设备信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;-- 查询传感器数据SELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;优势2支持复杂查询-- 改造前InfluxQL不支持JOIN-- 改造后SQL支持JOIN-- 查询设备最新状态和传感器数据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;优势3数据一致性-- 改造前tag变化导致数据冗余-- 改造后强类型保证数据一致性-- 更新设备信息UPDATEdevice_infoSETfirmware_versionv2.0WHEREdevice_iddevice_001;-- 查询设备信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;六、性能优化6.1 索引优化-- 创建主标签索引自动创建-- device_id已经是主标签自动索引-- 创建普通标签索引CREATEINDEXidx_locationONsensor_data(location);CREATEINDEXidx_statusONdevice_status(status);-- 创建时间索引自动创建-- time已经是主键的一部分自动索引6.2 分区优化-- 按时间分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 创建分区CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);6.3 查询优化-- 使用索引查询EXPLAINANALYZESELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;-- 使用分区查询EXPLAINANALYZESELECT*FROMsensor_data_2023_q1WHEREdevice_iddevice_001;七、常见问题7.1 高基数问题问题device_id数量过多导致主标签高基数解决方案-- 使用哈希分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYHASH(device_id);-- 创建分区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 数据类型问题问题InfluxDB的float类型在KaiwuDB中映射为DOUBLE解决方案-- 明确指定类型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,-- 明确使用FLOAThumidityFLOAT);7.3 时间精度问题问题InfluxDB默认使用纳秒精度KaiwuDB默认使用微秒精度解决方案-- 使用TIMESTAMPTZ保留时区信息CREATETABLEsensor_data(timeTIMESTAMPTZNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT);八、总结InfluxDB到KaiwuDB时序数据模型设计改造是迁移成功的关键。核心改造点主标签设计选择高选择性、稳定性、查询常用的字段普通标签设计选择辅助查询、低基数、可变性的字段字段列设计选择数值型、变化频繁、有聚合需求的字段表结构设计合理分区降低高基数影响关键经验理解模型差异InfluxDB和KaiwuDB的数据模型不同合理设计标签主标签和普通标签的选择很重要处理数据类型注意类型映射和精度问题优化查询性能利用KaiwuDB的SQL优势做好数据校验确保数据一致性如果你正在考虑InfluxDB迁移KaiwuDB建议先做好模型设计确保迁移后性能满足业务需求。转载自https://blog.csdn.net/u014727709/article/details/164125627欢迎 点赞✍评论⭐收藏欢迎指正
文章目录每日一句正能量一、前言模型改造是迁移的核心二、模型差异分析2.1 InfluxDB模型特点2.2 KaiwuDB模型特点2.3 模型对比三、表结构设计3.1 单表设计3.2 多表设计3.3 分区表设计四、标签设计优化4.1 主标签设计4.2 普通标签设计4.3 字段列设计五、模型改造实战5.1 改造前分析5.2 改造方案5.3 改造后优势六、性能优化6.1 索引优化6.2 分区优化6.3 查询优化七、常见问题7.1 高基数问题7.2 数据类型问题7.3 时间精度问题八、总结每日一句正能量你走的每一步都算数即使现在看不见回报时间会在未来的某个转角给你惊喜。所有经历都有价值回报可能延迟但一定会以某种形式出现。你读的书、熬的夜、练习的技能都在默默为那个“转角惊喜”编织底色。一、前言模型改造是迁移的核心前面十四篇文章我分享了MySQL和InfluxDB迁移KaiwuDB的完整经验。有读者问“迁移完成后发现原有的模型设计在KaiwuDB上并不合适查询性能不理想怎么办”这是个好问题。InfluxDB和KaiwuDB虽然都是时序数据库但数据模型设计理念不同。InfluxDB的tag/field模型灵活但查询受限KaiwuDB的主标签/普通标签/字段列模型更规范但需要合理设计。本文就把InfluxDB到KaiwuDB时序数据模型设计改造的完整经验分享出来包括模型差异分析、表结构设计、标签设计优化。二、模型差异分析2.1 InfluxDB模型特点InfluxDB采用measurement tag field模型Measurement: sensor_data Tags: device_id, location, status Fields: temperature, humidity, pressure Time: timestamp特点灵活tag和field可以动态添加自动索引tag自动创建索引无模式不需要预先定义表结构高写入适合高频写入场景问题高基数tag值过多导致性能下降查询受限不支持复杂SQL查询数据膨胀tag变化导致数据冗余2.2 KaiwuDB模型特点KaiwuDB时序引擎采用主标签 普通标签 字段列模型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);特点规范需要预先定义表结构强类型字段类型明确SQL支持支持标准SQL查询可扩展支持水平扩展优势查询灵活支持复杂SQL查询性能稳定不会因为高基数导致性能下降数据一致强类型保证数据一致性2.3 模型对比维度InfluxDBKaiwuDB说明数据模型measurement tag field主标签 普通标签 字段列概念对应模式定义无模式强模式KaiwuDB需要预先定义索引tag自动索引主标签自动索引都需要设计标签查询语言InfluxQLSQLKaiwuDB更标准高基数性能下降性能稳定KaiwuDB更优扩展性垂直扩展水平扩展KaiwuDB更优三、表结构设计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 分区表设计InfluxDB分区InfluxDB自动按时间分区不需要手动设计。KaiwuDB分区-- 按时间分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 创建分区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);四、标签设计优化4.1 主标签设计主标签选择原则高选择性值分布均匀避免热点稳定性值不会频繁变化查询常用经常用于WHERE条件InfluxDB tagtags: device_id, location, statusKaiwuDB主标签-- device_id作为主标签CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,humidityFLOAT);4.2 普通标签设计普通标签选择原则辅助查询用于过滤和分组低基数值数量不会太多可变性值可以变化InfluxDB tagtags: device_id, location, statusKaiwuDB普通标签-- location和status作为普通标签CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签location STRING,-- 普通标签statusSTRING,-- 普通标签temperatureFLOAT,humidityFLOAT);4.3 字段列设计字段列选择原则数值型温度、湿度、压力等变化频繁值会随时间变化聚合需求需要计算平均值、最大值等InfluxDB fieldfields: temperature, humidity, pressureKaiwuDB字段列-- temperature, humidity, pressure作为字段列CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,location STRING,temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT-- 字段列);五、模型改造实战5.1 改造前分析InfluxDB模型Measurement: sensor_data Tags: device_id, location, status, firmware_version Fields: temperature, humidity, pressure, voltage, current问题分析高基数firmware_version值变化频繁导致高基数数据膨胀tag变化导致数据冗余查询受限不支持复杂SQL查询5.2 改造方案KaiwuDB模型-- 主表设备基本信息CREATETABLEdevice_info(device_id STRINGPRIMARYKEY,location STRING,statusSTRING,firmware_version STRING,created_atTIMESTAMP);-- 时序表传感器数据CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签temperatureFLOAT,-- 字段列humidityFLOAT,-- 字段列pressureFLOAT,-- 字段列voltageFLOAT,-- 字段列currentFLOAT-- 字段列);-- 时序表设备状态CREATETABLEdevice_status(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,-- 主标签statusSTRING,-- 普通标签firmware_version STRING-- 普通标签);5.3 改造后优势优势1降低高基数-- 改造前firmware_version作为tag导致高基数-- 改造后firmware_version作为普通标签降低高基数-- 查询设备信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;-- 查询传感器数据SELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;优势2支持复杂查询-- 改造前InfluxQL不支持JOIN-- 改造后SQL支持JOIN-- 查询设备最新状态和传感器数据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;优势3数据一致性-- 改造前tag变化导致数据冗余-- 改造后强类型保证数据一致性-- 更新设备信息UPDATEdevice_infoSETfirmware_versionv2.0WHEREdevice_iddevice_001;-- 查询设备信息SELECT*FROMdevice_infoWHEREdevice_iddevice_001;六、性能优化6.1 索引优化-- 创建主标签索引自动创建-- device_id已经是主标签自动索引-- 创建普通标签索引CREATEINDEXidx_locationONsensor_data(location);CREATEINDEXidx_statusONdevice_status(status);-- 创建时间索引自动创建-- time已经是主键的一部分自动索引6.2 分区优化-- 按时间分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYRANGE(time);-- 创建分区CREATETABLEsensor_data_2023_q1PARTITIONOFsensor_dataFORVALUESFROM(2023-01-01)TO(2023-04-01);6.3 查询优化-- 使用索引查询EXPLAINANALYZESELECT*FROMsensor_dataWHEREdevice_iddevice_001ANDtimenow()-INTERVAL1 hour;-- 使用分区查询EXPLAINANALYZESELECT*FROMsensor_data_2023_q1WHEREdevice_iddevice_001;七、常见问题7.1 高基数问题问题device_id数量过多导致主标签高基数解决方案-- 使用哈希分区CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT,PRIMARYKEY(time,device_id))PARTITIONBYHASH(device_id);-- 创建分区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 数据类型问题问题InfluxDB的float类型在KaiwuDB中映射为DOUBLE解决方案-- 明确指定类型CREATETABLEsensor_data(timeTIMESTAMPNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,-- 明确使用FLOAThumidityFLOAT);7.3 时间精度问题问题InfluxDB默认使用纳秒精度KaiwuDB默认使用微秒精度解决方案-- 使用TIMESTAMPTZ保留时区信息CREATETABLEsensor_data(timeTIMESTAMPTZNOTNULL,device_id STRINGNOTNULL,temperatureFLOAT,humidityFLOAT);八、总结InfluxDB到KaiwuDB时序数据模型设计改造是迁移成功的关键。核心改造点主标签设计选择高选择性、稳定性、查询常用的字段普通标签设计选择辅助查询、低基数、可变性的字段字段列设计选择数值型、变化频繁、有聚合需求的字段表结构设计合理分区降低高基数影响关键经验理解模型差异InfluxDB和KaiwuDB的数据模型不同合理设计标签主标签和普通标签的选择很重要处理数据类型注意类型映射和精度问题优化查询性能利用KaiwuDB的SQL优势做好数据校验确保数据一致性如果你正在考虑InfluxDB迁移KaiwuDB建议先做好模型设计确保迁移后性能满足业务需求。转载自https://blog.csdn.net/u014727709/article/details/164125627欢迎 点赞✍评论⭐收藏欢迎指正
平方复杂度无法被常规优化消除｜TaoToken 统一 Key 通道实测)
