数据库模型
本文档说明平台在哪里以什么形式存储数据。制定备份范围、直接查询或调整保留周期时参考。
平台根据数据特性分别使用不同存储（polyglot persistence）。如果不知道某类数据存在哪里，备份就会不完整。
| 存储 | 内容 | 规模 |
|---|---|---|
| PostgreSQL | 主数据 · 配置 · 事务 | 43 张表 |
Cassandra (pp) | 时序 · 事件 · 聚合 | 99 张表 |
Iceberg (spark.plantpulse) | 长期保管 · 分析 | 1 张表 |
PostgreSQL — 主数据和配置
存储关系型数据。模式变更由 Flyway 管理，变更历史保存在
flyway_schema_history 中。
表名大多带有 mm_ 前缀（master/meta），共 36 个。
| 分组 | 表 |
|---|---|
| 组织·资产 | mm_company · mm_site · mm_asset_tree · mm_asset_type · mm_asset_status · mm_asset_statement · mm_asset_statement_plugin |
| 采集定义 | mm_opc · mm_tag · mm_point · mm_scada |
| 报警 | mm_alarm · mm_alarm_config · mm_alarm_recieve_users |
| 事件·触发 | mm_event · mm_event_attributes · mm_trigger · mm_trigger_attributes |
| 生产 | mm_order · mm_order_flow · mm_order_oee · mm_oee · mm_product · mm_shift · mm_calendar · mm_calendar_type |
| 人员·交易方 | mm_employee · mm_customer |
| 屏幕·查询 | mm_dashboard · mm_graph · mm_statement · mm_query_history |
| 安全 | mm_security · mm_token · user_login · user_login_session |
| 其他 | mm_blob · mm_metadata · metadata · version · version_history · dual |
mm_alarm_recieve_users 的拼写不是 receive，而是 recieve。这个拼写错误已经固化在模式中，查询时必须原样书写。
Cassandra — 时序和事件
键空间为 pp。99 张表分为两大类。
| 前缀 | 数量 | 含义 |
|---|---|---|
tm_ | 91 | 时序·聚合·统计（time series measurement） |
ts_ | 8 | 通用时序引擎内部结构 |
tm_ 按对象再分——标签 32 · 资产 22 · 系统 6 · 监视 6 · 选项 5 · OPC 5 · 站点 3 · blob 3 等。
核心表 — tm_tag_point
存储原始采集值。其余标签表大多是它的派生。
PRIMARY KEY (tag_id, timestamp)
WITH CLUSTERING ORDER BY (timestamp DESC)
| 特性 | 值 |
|---|---|
| 分区键 | tag_id — 每个标签一个分区 |
| 聚类 | timestamp 降序 — 基本读取方向是最新优先 |
| 默认 TTL | 5356800 秒 = 62 天 |
| 压缩 | UnifiedCompactionStrategy（Cassandra 5.0+） |
| 索引 | asset_id · opc_id 上的 SAI（Storage Attached Index） |
site_id · asset_id · line_id · area_id · opc_id · tag_name · type 是
static 的。在一个标签（=一个分区）内值相同，因此每个分区只存储一次。
不必在每个数据点重复存储，大幅节省容量。
派生表 — 预先计算
Cassandra 查询时聚合成本高，所以采用写入时预计算。这就是为什么表很多。
| 类别 | 例 |
|---|---|
| 聚合 | tm_tag_point_aggregation_{1,5,10,30}_minutes · _1_hours |
| 采样 | tm_tag_point_sampling_{10,30}_seconds · _{1,5,10,30}_minutes · _1_hours |
| 计数 | tm_tag_point_count · _by_date · _by_opc · _by_site |
| 质量·验证 | tm_tag_point_validation · _by_timestamp · _validation_count |
| AI 分析 | tm_tag_point_anomalies · _forecasts |
| 快照·保管 | tm_tag_point_snapshot · tm_tag_point_archive |
报警采用相同方式 — tm_tag_alarm 及 _count · _count_by_date · _count_by_opc · _count_by_site · _duration · _on。
不会从原始数据重新生成。删除后该时间段的屏幕和报表会留空，只能从备份恢复。
Iceberg — 长期保管
超过 Cassandra TTL（62 天）的数据堆积在对象存储中进行分析。
| 项 | 值 |
|---|---|
| 目录 | spark.plantpulse |
| 表 | tm_tag_point_warehouse |
| 分区 | site_id → year → month → day |
| 格式 | Iceberg v2（支持行级删除） |
| 压缩 | Zstandard |
| 执行 | Spark SQL |
Cassandra 中没有。查询 Iceberg 一侧 → 分析层。
备份中容易遗漏的部分
三个存储都是独立的备份对象。有时只备份 PostgreSQL 就以为万事大吉， 结果时序数据整个丢失。
| 存储 | 丢失后果 |
|---|---|
| PostgreSQL | 设备·标签定义、用户、仪表板消失 |
| Cassandra | 最近 62 天数据消失 |
| Iceberg / 对象存储 | 历史数据消失 |
详见备份和恢复。