一、场景需求分析

1. 数据规模‌

   • ‌设备数量‌: 1000台设备

   • ‌采集频率‌: 每10秒/次，每秒写入请求量：1000/10=100次/s

   • ‌单次数据量‌: 每个设备包含5个指标（温度、湿度、位置、放射强度、电量），每次写入5个数据点

   • ‌日数据量‌: 1000设备 * 5指标 * 8640次/天 ≈ 43.2M数据点/天

2. ‌核心需求‌

   • 高频写入稳定性

   • 实时查询（如最新状态、阈值告警）

   • 历史数据聚合分析（如24小时内温度趋势）

   • 数据存储成本控制

二、InfluxDB vs MySQL核心对比

维度‌	‌InfluxDB‌	‌MySQL‌
‌数据模型‌	时间序列数据模型，内置时间戳、Tag（设备ID）、Field（指标值）	关系型模型，需设计时间戳字段+设备ID+指标字段
‌写入性能‌	支持批量写入，每秒可处理10万+数据点（TSM引擎优化）	单表高频写入易成瓶颈，需分库分表或批量插入优化
‌存储效率‌	列式存储+压缩算法（TSM），相同数据量占磁盘空间约为MySQL的1/5	行式存储+索引开销，存储空间较大
‌查询性能‌	毫秒级响应时间序列范围查询，内置时间窗口聚合函数	复杂时间范围查询需依赖索引，聚合计算效率较低
‌扩展性‌	原生支持集群化部署（企业版），横向扩展便捷	需依赖分库分表或中间件（如Vitess），运维复杂度高
‌数据保留策略‌	内置TTL自动过期机制，按时间自动清理旧数据	需手动清理或通过定时任务维护
‌适用场景‌	实时监控、高频写入、时间序列分析	事务处理、复杂关联查询、业务数据持久化

三、数据模型设计示例

1. ‌InfluxDB 数据模型

Measurement: logistics_box  
Tags: device_id (物流箱唯一ID)  
Fields: temperature, humidity, location, radiation, battery  
Timestamp: 自动生成或由MQTT消息携带

查询示例‌：统计某设备过去1小时的平均温度

SELECT MEAN(temperature) FROM logistics_box 
WHERE device_id='BOX-001' AND time > now() - 1h

2. ‌MySQL 数据模型

CREATE TABLE logistics_data (
    id INT AUTO_INCREMENT PRIMARY KEY,
    device_id VARCHAR(32) NOT NULL,
    timestamp DATETIME NOT NULL,
    temperature FLOAT,
    humidity FLOAT,
    location POINT,
    radiation FLOAT,
    battery FLOAT,
    INDEX idx_device_time (device_id, timestamp)
);

查询示例‌：获取某设备最新状态

SELECT * FROM logistics_data WHERE device_id='BOX-001' ORDER BY timestamp DESC LIMIT 1

四、C# .NET Core集成实现

1. ‌MQTT数据接收‌

// 使用 MQTTnet 库接收消息
var factory = new MqttFactory();
var mqttClient = factory.CreateMqttClient();
await mqttClient.ConnectAsync(options);
​
mqttClient.ApplicationMessageReceivedAsync += e => {
    var payload = Encoding.UTF8.GetString(e.ApplicationMessage.Payload);
    var data = JsonConvert.DeserializeObject<LogisticsData>(payload);
    // 写入数据库（见下文）
    return Task.CompletedTask;
};
​

2. ‌InfluxDB写入优化（批量提交）

// 使用 InfluxDB.Client 库
var point = PointData.Measurement("logistics_box")
    .Tag("device_id", data.DeviceId)
    .Field("temperature", data.Temperature)
    .Field("humidity", data.Humidity)
    // ...其他字段
    .Timestamp(data.Timestamp, WritePrecision.Ns);
​
using var client = InfluxDBClientFactory.Create("http://localhost:8086", "token");
using var writeApi = client.GetWriteApi();
writeApi.WritePoint("bucket", "org", point);  // 支持批量WritePoints

3. ‌MySQL写入优化（批量插入）

// 使用 Dapper 批量插入
var sql = @"INSERT INTO logistics_data 
            (device_id, timestamp, temperature, humidity, ...)
            VALUES (@DeviceId, @Timestamp, @Temperature, @Humidity, ...)";
using var connection = new MySqlConnection(connectionString);
await connection.ExecuteAsync(sql, dataList);  // dataList为批量数据集合

五、性能压测对比（模拟结果）

‌指标‌	‌InfluxDB‌	‌MySQL‌
写入吞吐量	12K数据点/秒	2K数据点/秒（无分表）
查询最新数据延迟	<10ms	50-200ms（依赖索引）
24h数据聚合查询	100ms	2-5s
磁盘占用（1天）	~2GB	~10GB

六、选型建议

1. ‌优先选择InfluxDB‌

   • 若以‌实时监控、高频写入、时间聚合‌为核心需求，InfluxDB在性能和存储效率上显著占优，适合直接与Grafana集成实现可视化大屏。

2. ‌结合MySQL的混合方案‌

   • 若需‌关联业务数据‌（如物流订单信息），可将InfluxDB用于实时指标存储，MySQL用于业务数据管理，通过设备ID关联查询。

3. ‌成本敏感场景‌

   • 开源版InfluxDB单节点可支持此规模数据，企业版需按集群需求评估成本；MySQL需投入更多硬件资源优化分表策略。

七、扩展优化建议

• ‌InfluxDB调优‌：启用TSI索引加速设备ID查询，设置保留策略自动清理过期数据。

• ‌MySQL调优‌：使用分区表按时间范围划分，启用压缩功能（如TokuDB引擎）。

• ‌架构扩展‌：引入Kafka缓冲MQTT数据，削峰填谷保障写入稳定性。

通过以上方案，可平衡性能、成本与开发复杂度，满足设备监控场景的实时性需求。