Datenbankmodell
Dokumentation darüber, wo und in welcher Form die Plattform Daten speichert. Sie wird herangezogen, um Backup-Bereiche festzulegen, direkte Abfragen durchzuführen oder Aufbewahrungsdauern anzupassen.
Die Plattform nutzt unterschiedliche Speicher je nach Datentyp (polyglot persistence). Wenn Sie nicht wissen, wo welche Daten liegen, wird Ihr Backup unvollständig.
| Speicher | Inhalt | Umfang |
|---|---|---|
| PostgreSQL | Masterdaten · Konfiguration · Transaktionen | 43 Tabellen |
Cassandra (pp) | Zeitreihen · Ereignisse · Aggregate | 99 Tabellen |
Iceberg (spark.plantpulse) | Langzeitarchivierung · Analyse | 1 Tabelle |
PostgreSQL — Masterdaten und Konfiguration
Hier werden relationale Daten gespeichert. Schemänderungen werden von Flyway verwaltet, und die Historie wird unter flyway_schema_history protokolliert.
Tabellennamen haben überwiegend mm_ Präfixe (master/meta) — insgesamt 36.
| Gruppe | Tabellen |
|---|---|
| Organisation · Anlage | mm_company · mm_site · mm_asset_tree · mm_asset_type · mm_asset_status · mm_asset_statement · mm_asset_statement_plugin |
| Erfassungsdefinitionen | mm_opc · mm_tag · mm_point · mm_scada |
| Alarme | mm_alarm · mm_alarm_config · mm_alarm_recieve_users |
| Ereignisse · Trigger | mm_event · mm_event_attributes · mm_trigger · mm_trigger_attributes |
| Produktion | mm_order · mm_order_flow · mm_order_oee · mm_oee · mm_product · mm_shift · mm_calendar · mm_calendar_type |
| Personen · Partner | mm_employee · mm_customer |
| Dashboards · Abfragen | mm_dashboard · mm_graph · mm_statement · mm_query_history |
| Sicherheit | mm_security · mm_token · user_login · user_login_session |
| Sonstiges | mm_blob · mm_metadata · metadata · version · version_history · dual |
mm_alarm_recieve_usersEs ist recieve, nicht receive. Der Tippfehler hat sich im Schema verfestigt; Sie müssen ihn beim Schreiben von Abfragen genau so übernehmen.
Cassandra — Zeitreihen und Ereignisse
Der Keyspace heißt pp. Die 99 Tabellen teilen sich in zwei Kategorien auf.
| Präfix | Anzahl | Bedeutung |
|---|---|---|
tm_ | 91 | Zeitreihen · Aggregate · Statistiken (time series measurement) |
ts_ | 8 | Interne Struktur der Universal-Zeitreihen-Engine |
tm_ unterteilen sich weiter nach Ziel — Tags 32 · Anlagen 22 · System 6 · Monitore 6 · Optionen 5 · OPC 5 · Standorte 3 · blob 3 usw.
Kernelle Tabelle — tm_tag_point
Dies ist der Speicherort für Roherfassungswerte. Die meisten anderen Tag-Tabellen sind Ableitungen davon.
PRIMARY KEY (tag_id, timestamp)
WITH CLUSTERING ORDER BY (timestamp DESC)
| Merkmal | Wert |
|---|---|
| Partitionsschlüssel | tag_id — ein Tag pro Partition |
| Clustering | timestamp absteigend — neueste Einträge zuerst zu lesen ist Standard |
| Standard-TTL | 5356800 Sekunden = 62 Tage |
| Compaction | UnifiedCompactionStrategy (Cassandra 5.0+) |
| Indizes | SAI (Storage Attached Index) auf asset_id · opc_id |
site_id · asset_id · line_id · area_id · opc_id · tag_name · type sind
static. Innerhalb einer Partition (= ein Tag) haben sie denselben Wert, daher wird dieser pro Partition nur einmal gespeichert.
Sie werden nicht bei jedem Datenpunkt wiederholt, was Speicherplatz erheblich spart.
Abgeleitete Tabellen — vorberechnet
Cassandra macht Laufzeit-Aggregation teuer, daher werden Aggregate bereits beim Schreiben vorberechnet. Das erklärt die hohe Tabellenzahl.
| Kategorie | Beispiele |
|---|---|
| Aggregate | tm_tag_point_aggregation_{1,5,10,30}_minutes · _1_hours |
| Sampling | tm_tag_point_sampling_{10,30}_seconds · _{1,5,10,30}_minutes · _1_hours |
| Zähler | tm_tag_point_count · _by_date · _by_opc · _by_site |
| Qualität · Validierung | tm_tag_point_validation · _by_timestamp · _validation_count |
| KI-Analyse | tm_tag_point_anomalies · _forecasts |
| Snapshots · Archivierung | tm_tag_point_snapshot · tm_tag_point_archive |
Alarme folgen demselben Muster — tm_tag_alarm und _count · _count_by_date · _count_by_opc · _count_by_site · _duration · _on.
Sie werden nicht aus den Rohdaten rekonstruiert. Wenn Sie sie löschen, werden Dashboards und Berichte für diesen Zeitraum leer, und Wiederherstellung ist nur aus dem Backup möglich.
Iceberg — Langzeitarchivierung
Daten, die das Cassandra-TTL (62 Tage) überschreiten, werden in Objektspeicher für Analyse gestapelt.
| Element | Wert |
|---|---|
| Katalog | spark.plantpulse |
| Tabelle | tm_tag_point_warehouse |
| Partitionierung | site_id → year → month → day |
| Format | Iceberg v2 (row-level delete unterstützt) |
| Kompression | Zstandard |
| Ausführung | Spark SQL |
Sie sind nicht in Cassandra. Abfrage auf der Iceberg-Seite → Analyseschicht.
Häufig übersehene Backup-Punkte
Die drei Speicher sind jeweils Backup-Ziele. Manche sichern nur PostgreSQL und denken, das reicht – aber dann fehlen alle Zeitreihen.
| Speicher | Folge des Ausfalls |
|---|---|
| PostgreSQL | Anlagen- und Tag-Definitionen, Benutzer und Dashboards verschwinden |
| Cassandra | Aktuelle 62 Tage Daten verschwinden |
| Iceberg / Objektspeicher | Langzeithistorie verschwindet |
Das Verfahren finden Sie unter Backup und Wiederherstellung.
Zugehörige Dokumentation
- Backup und Wiederherstellung
- Speicherschicht · Analyseschicht
- Domain-ID-Regeln —
SITE_·ASSET_·TAG_Präfixe - Datenbankverwaltung — Installation und Betrieb