飞行控制系统的状态数据（如传感器数据、控制指令、系统日志）需要存储，请设计一个数据库模型，并说明如何保证数据的一致性和实时性。需考虑数据类型、数据库选择、模型设计及优化策略。

1) 【一句话结论】采用时序数据库（如TimescaleDB）存储传感器等实时数据，关系型数据库（如PostgreSQL）存储结构化控制指令和日志，通过ACID事务保证一致性，结合分区、索引和消息队列优化实时性。

2) 【原理/概念讲解】
老师：咱们先拆解飞行控制系统的状态数据类型，这直接决定数据库选择。

• 传感器数据（如GPS、IMU）：时间序列、高频率（比如GPS每100ms采集一次），特点是“按时间顺序、高写入频率”；
• 控制指令（如舵机控制）：结构化、低延迟（比如指令需快速响应），特点是“少量写入、强一致性”；
• 系统日志：文本、可追溯（如错误日志），特点是“少量写入、需长期存储”。

接下来选数据库：

• 时序数据库（如TimescaleDB）：专为时间序列设计，支持时间索引、自动分区、高效聚合查询，适合传感器数据；
• 关系型数据库（如PostgreSQL）：符合ACID事务，支持复杂查询（如JOIN），适合结构化控制指令和日志。

一致性方面，用ACID事务保证强一致性（比如插入传感器数据后立即更新指令状态，确保数据同步）；实时性方面，通过分区策略（按时间/传感器ID）和索引优化（时间索引、类型索引）减少查询延迟。

3) 【对比与适用场景】

数据库类型	定义	核心特性	适用场景	注意点
时序数据库（TimescaleDB）	基于时间序列的数据库，支持时间索引和聚合	高效时间范围查询、自动分区、支持复杂聚合	传感器数据、日志、实时监控（如温度、速度等时间序列）	不适合复杂关联查询
关系型数据库（PostgreSQL）	符合ACID的事务型数据库	强一致性、事务支持、复杂查询（JOIN）	结构化数据（控制指令、系统配置）	写入延迟较高

4) 【示例】
设计表结构：

• 传感器数据表（TimescaleDB）：

  CREATE TABLE sensor_data (
      id SERIAL PRIMARY KEY,
      sensor_id INT NOT NULL,
      timestamp TIMESTAMPTZ NOT NULL,
      value FLOAT NOT NULL,
      unit VARCHAR(10) NOT NULL,
      PRIMARY KEY (sensor_id, timestamp)
  );
  

• 控制指令表（PostgreSQL）：

  CREATE TABLE control_commands (
      command_id UUID PRIMARY KEY,
      timestamp TIMESTAMPTZ NOT NULL,
      command_type VARCHAR(50) NOT NULL,
      payload JSONB NOT NULL,
      status VARCHAR(20) DEFAULT 'pending'
  );
  

• 系统日志表（PostgreSQL）：

  CREATE TABLE system_logs (
      log_id UUID PRIMARY KEY,
      timestamp TIMESTAMPTZ NOT NULL,
      level VARCHAR(10) NOT NULL,
      message TEXT NOT NULL
  );
  

一致性保证：使用事务，比如插入传感器数据后更新指令状态：

BEGIN;
INSERT INTO sensor_data (sensor_id, timestamp, value, unit) VALUES (1, NOW(), 100.5, 'm/s');
UPDATE control_commands SET status = 'executed' WHERE command_id = 'cmd_123';
COMMIT;

实时性优化：

• 传感器数据表按sensor_id和timestamp分区（如按天分区）；
• 控制指令表按command_type分区（如按指令类型分区）；
• 建立索引：sensor_data的timestamp索引、control_commands的command_type索引。

5) 【面试口播版答案】
面试官您好，针对飞行控制系统的状态数据存储，我的核心设计思路是采用时序数据库+关系型数据库的混合模型，结合事务和分区策略保证一致性与实时性。

首先，传感器数据（如GPS、IMU）是高频率时间序列，适合用TimescaleDB存储，它能高效处理时间范围查询和聚合；控制指令（如舵机控制）是结构化、低延迟数据，用PostgreSQL存储，支持复杂查询和事务。

一致性方面，通过ACID事务保证强一致性，比如插入传感器数据后立即更新指令状态，确保数据同步。实时性优化上，对传感器数据表按sensor_id和timestamp分区，控制指令表按command_type分区，并建立时间索引和类型索引，减少查询延迟。这样既能满足实时数据的高效写入，又能保证数据的一致性。

6) 【追问清单】

• 问题：如何处理数据量爆炸的问题？
  回答要点：使用分区策略（按时间/传感器ID）和分片，结合数据压缩（如时序数据压缩）降低存储压力。
• 问题：如何保证跨节点数据一致性？
  回答要点：使用分布式事务（如两阶段提交）或最终一致性结合消息队列（如Kafka）确保数据最终一致。
• 问题：如果系统需要实时监控和告警，数据库如何支持？
  回答要点：时序数据库支持实时聚合查询（如每秒计算平均速度），关系型数据库支持告警规则存储（如告警阈值配置）。

7) 【常见坑/雷区】

• 只选单一数据库：忽略不同数据类型的需求，导致性能或一致性不足；
• 一致性模型选择错误：用最终一致性但实时性要求高，导致数据不一致；
• 未考虑分区导致查询慢：未对大数据量进行分区，查询时全表扫描，影响实时性；
• 未说明数据清洗：传感器数据可能有噪声，未设计数据清洗流程，影响数据准确性；
• 未考虑容灾：未设计备份和恢复策略，导致数据丢失风险。