Datenbankmodell

Dieses Dokument beschreibt, wo und in welcher Form der AI-Stack Daten ablegt. Es gibt vier Speicher, und jeder hat eine andere Rolle. Betriebsabläufe siehe Datenbankverwaltung.

Die meisten Speicher gehören nicht der AI

PostgreSQL · Aster TSDB werden gemeinsam mit der PlantPulse-Platform-Installation genutzt. Der AI-Stack startet keine eigene DB. Dadurch überschneiden sich „AI-Backup" und „Platform-Backup" — wenn nicht klar festgelegt ist, wer was sichert, fallen bei beiden Lücken auf.

Speicher	Eigentümer	Inhalt
PostgreSQL `pi` · Schema `co`	AI (separate DB innerhalb der Platform-PG)	Chat · Incident · Konfiguration · MCP (Copilot)
PostgreSQL `pi` · Schema `dt`	AI (〃)	Register für externe Systemkonnektoren · Bindungen · Aktionsprotokoll (Digital Thread)
PostgreSQL `lightrag`	AI (〃)	Dokumentenverarbeitungsstatus von LightRAG (`PGDocStatusStorage`)
PostgreSQL `rag_ingest`	AI (〃)	Status der Dokumenten-Ingestion-Pipeline (rag-api) — siehe unten „PostgreSQL rag_ingest"
PostgreSQL `litellm`	AI (〃)	Schlüssel · Nutzung des LiteLLM-Gateways
Aster TSDB `pi`	AI	Feature Store · Ergebnisse der Anomalieerkennung
Aster TSDB `pp`	Platform (nur lesend)	Rohe Sensordaten · Alarm · OEE
Neo4j `plantpulse-neo4j`	AI	Wissensgraph von LightRAG
Neo4j `plantpulse-digital-thread-neo4j`	AI	Spiegel des Werksgraphen des Digital Thread — nur Referenz
Qdrant	AI	Embedding-Vektoren der Dokumente
`lightrag-storage` Volume	AI	KV-Cache von LightRAG — lokale JSON-Datei
`lightrag-inputs` Volume	AI	Hochgeladene Originaldokumente

Es gibt „vier" DBs der AI in der Platform-PG

Die AI startet keine eigene PostgreSQL, sondern nutzt die PostgreSQL der Platform. Darin werden vier DBs pi · lightrag · rag_ingest · litellm angelegt (idempotent durch provision-platform-db.sh). pi ist eine von den AI-Apps gemeinsam genutzte DB, und jede App hat ein eigenes Schema (co Copilot · dt Digital Thread). Die DB ch aus Versionen 2026.09 und früher wird beim Hochfahren nach pi.co verschoben → Datenbankverwaltung. Aster TSDB · Valkey · RustFS · der MQTT-Broker (Abonnement von Anlagenalarmen) werden ebenfalls von der Platform mitgenutzt — rechnen Sie diese vier bei der Dimensionierung der AI-Box nicht separat ein.

PostgreSQL `pi.co` — Dialog- und Betriebsstatus

Dies ist das Schema co einer separaten Datenbank pi innerhalb der Platform-PostgreSQL (jdbc:postgresql://<platform-host>:5432/pi?currentSchema=co). Der Copilot sieht und verbindet sich ausschließlich mit diesem Schema, daher gelten alle Tabellennamen ohne Schema-Präfix als co.

Identische Tabelle wie ch aus Version 2026.09 und früher

Früher lagen diese Tabellen in public der DB ch. Name und Form sind unverändert, nur der Speicherort wurde nach pi.co verlegt.

Gruppe	Tabelle
Dialog	`chats` · `chat_messages` · `prompts` · `prompt_history` — `chats.context` ist im Dialog fixierter Kontext (Re-Release 2026.10)
Chat-Verhalten · Antwortqualität (Re-Release 2026.10)	`chat_action` (ein Entwurfsvorschlag in einer Chat-Antwort = eine Zeile — wer, wann, warum genehmigt hat) · `chat_turn_metric` (pro beantwortetem Turn: Latenz · Tokens · Modell · Anzahl Zitate · Art der Belege · 👍👎, sowie das Ergebnis-Flag `outcome` — leer bedeutet normale Antwort, `no_answer` auch nach Wiederholung leere Antwort, `loop_cut` bricht die Wiederholung ab) · `chat_bench_run` (Benchmark-Durchlauf-Ergebnisse)
Benutzer	`users` · `user_roles` · `employees` · `web_push_subscription` — `employees.work_role` ist die vom Administrator festgelegte Arbeitsrolle (Genehmigungsbefugnis), `employees.home_role` ist der in der alten Oberfläche selbst gewählte Startbildschirm (Re-Release 2026.10 Punkt 3 — in der neuen Oberfläche nicht mehr verwendet) → Arbeitsrollen
Incident (Tabellenname bleibt `incident`)	`incident` · `incident_event` · `assignees`
Watch (Bedingungsüberwachung — entfallene Funktion)	`watch` · `watch_run`. Seit der Oberflächenablösung werden sie weder angelegt noch genutzt. Tabellen aus älteren Installationen bleiben unverändert bestehen
Betrieb der Anomalieerkennung	`anomaly_mute` · `hourly_anomaly` · `asset_tag_profile`
MCP · Werkzeuge	`agent_tool_call_log` — bei einer von einem Menschen genehmigten Aktion wird der Genehmiger in `approved_by` festgehalten. Die alten Tabellen `mcp_server` · `mcp_tool_pref` · `mcp_tool_call_log` löscht der Start in 2026.10 Re-Release (2026-10-20) — maßgeblich für Server · Ein/Aus · Aufrufprotokoll ist die DB des MCP Gateway (Schema `gw` in `pi`)
Öffentliche API	`api_key`
Konfiguration	`config` · `config_audit_log` · `metadata`

Neue Tabellen · Spalten entstehen automatisch beim Hochfahren

Die oben genannten „Re-Release 2026.10"-Tabellen und -Spalten werden beim Hochfahren des Copilot automatisch über CREATE TABLE IF NOT EXISTS · ADD COLUMN IF NOT EXISTS erzeugt. Es gibt keine manuell auszuführende Migration. chat_turn_metric enthält weder Frage- noch Antworttext (der Originaltext steht in chat_messages), chat_action enthält weder Sprache noch Antworttext — nur Werkzeugargumente und Ergebniscodes.

Werkzeugaufruf-Hauptbuch agent_tool_call_log

Jeder von der AI aufgerufene Werkzeugaufruf wird lückenlos hier festgehalten — Zeitpunkt · Benutzer · Sitzung · Werkzeugname · Quell-MCP-Server · Argumente (Geheimwerte maskiert durch ***) · Ergebnis (ok · error · denied) · benötigte Zeit. denied sind Aufrufe von ändernden Werkzeugen, die vom Genehmigungs-Gate blockiert wurden → MCP. mcp_tool_call_log enthält nur Erfolgs- und Zeitstatistiken je registriertem MCP-Server — „wer hat was getan" sehen Sie in dieser Tabelle.

Öffentliche API-Schlüssel api_key

Schlüssel werden nicht im Klartext gespeichert — nur Hash (key_hash) und ein erkennbares Präfix (key_prefix) werden abgelegt. Beim Widerruf wird die Zeile nicht gelöscht, sondern revoked_at gesetzt. Ist last_used_at leer, wird der Schlüssel nicht verwendet → Copilot-Verwaltungskonsole.

Der Chatverlauf hat hier seine einzige Quelle der Wahrheit

Vor der Umstellung 2026-07 gab es auch im Aster TSDB einen Dialogverlauf. Jetzt ist chat_messages die einzige Quelle. Suchen Sie nicht anhand alter Dokumentation im Aster TSDB danach.

PostgreSQL `pi.dt` — Register des Digital Thread

Dieses Schema gehört der Digital-Thread-API. Die Tabellen werden beim Hochfahren des Dienstes erzeugt. Alle Anweisungen sind auf dt. beschränkt und berühren kein anderes Schema.

Gruppe	Tabelle
Konnektor	`dt_connector` · `dt_connector_tool`
Bindung	`dt_binding` · `dt_binding_log` (vom Operator festgelegte Kanalbindungen und deren Änderungsprotokoll — wer · wann · vorher/nachher)
Aktionsprotokoll	`dt_action_log` (genehmigte Entwürfe/Anfragen, die an externe Systeme gesendet wurden)
Episode	`dt_episode` · `dt_episode_label`
Identitätsdeklaration	`dt_identity` · `dt_identity_log` (Operator-Deklaration „Schlüssel A und Schlüssel B sind an diesem Standort dasselbe" und deren Änderungsprotokoll — wird nicht automatisch verknüpft)

Konnektor-Zugangsdaten lassen sich ohne Verschlüsselungsschlüssel nicht entschlüsseln

Die Zugangsdaten in dt_connector werden versiegelt mit PI_DT_SECRET_KEY gespeichert. Geht dieser Schlüssel verloren, können die gespeicherten Zugangsdaten auch nach Wiederherstellung der DB nicht genutzt werden — sie müssen für jeden Konnektor erneut eingegeben werden. Sichern Sie ihn zusammen mit der Host-env-Datei → Digital Thread.

PostgreSQL rag_ingest — Status der Dokumenten-Ingestion

Diese DB gehört rag-api. Die Tabellen werden beim Hochfahren von rag-api erzeugt (idempotent).

Gruppe	Tabelle	Wann entsteht sie
Synchronisation	`rag_asset_doc_sync` · `rag_sync_run` · `rag_asset_card`	immer
Zeichnung	`rag_drawing_doc` · `rag_drawing_chunk` · `rag_drawing_ident` · `rag_drawing_dim` · `rag_drawing_kg` · `rag_drawing_outbox`	nur wenn `DRAWING_INGEST_ENABLED=true`
Video · Audio	`rag_media_job` · `rag_media_segment` · `rag_media_sidecar`	nur in Installationen mit aktiviertem Video/Audio (`PI_MEDIA_ENABLED=true` — in rag-api `MEDIA_INGEST_ENABLED=true`)

rag_drawing_doc.source gibt an, woher die Zeichnung stammt — hochgeladen über die Verwaltungskonsole (MANUAL) oder eingebracht durch die Synchronisation, die Platform-Anlagendokumente übernimmt (PLATFORM, Re-Release 2026.10 Punkt 3). Letzteres gilt als autoritativ von der Platform und wird in der Konsole nicht überschrieben oder gelöscht.
rag_drawing_dim enthält pro Maßzeile Ober-/Untergrenze (upper_limit · lower_limit) sowie deren Grundlage (limits_basis — ob der Wert auf der Zeichnung steht, oder eine „Formelschätzung" über eine Passungsformel ist).
rag_media_job entspricht einer Zeile pro Video-/Audiodatei (Herkunft source · Verarbeitungsstatus · Anzahl Versuche · Anzahl Thumbnails usw.). Der Bildschirm RAG › Index › Video der Verwaltungskonsole zeigt diese Daten → Video- · Audiosuche.

Struktur/Vorschau der Zeichnungs-Originale und Videoaufzeichnungen liegen nicht in Tabellen, sondern im Objektspeicher-Bucket plantpulse-rag → Datenbankverwaltung.

Aster TSDB `pi` — Feature Store

12 Tabellen, die der Zeitreihen-Insight-Dienst besitzt und erzeugt. Das Präfix ist tsi_.

Gruppe	Tabelle
Feature	`tsi_tag_feature_hourly` · `tsi_tag_feature_daily` · `tsi_asset_feature_hourly` · `tsi_asset_feature_daily`
Kontext·Profil	`tsi_asset_context_daily` · `tsi_asset_profile`
Anomalie·Störung	`tsi_anomaly_embedding` · `tsi_failure_signature` · `tsi_precursor_alert`
Pipeline	`tsi_pipeline_status` · `tsi_pipeline_history` · `tsi_backfill_status`

Die Tabellen werden beim Hochfahren des Dienstes idempotent erzeugt. Jedoch wird der Keyspace pi selbst nicht von der App angelegt — dafür ist das Installationsskript (provision-platform-db.sh) zuständig.

Sind die Features leer, bleibt der gesamte Analysebildschirm leer

Die Bildschirme für Anomalieerkennung und Prognose in der Verwaltungskonsole lesen ausschließlich diese Tabellen. Sind die Ergebnisse leer, prüfen Sie zuerst nicht das Modell, sondern die Pipeline → Pipeline Status / Run History der Verwaltungskonsole (AI-Verwaltungskonsole).

Auch die Tabellen des Copilot liegen im selben Keyspace

Auch der Copilot legt seine eigenen Tabellen (z. B. Morgenkarten) in pi ab. Mit Re-Release 2026.10 kam PI_NAVIGATOR_ACTION_CHECK hinzu, das den Erledigungsstatus von Maßnahmen aus strukturierten Berichten enthält; der Copilot erzeugt diese Tabelle beim Hochfahren.

Der alte pp.ti_* existiert nicht mehr

Am 2026-07-30 wurde vom Keyspace pp nach pi verschoben, und die alte Tabelle wurde per DROP entfernt. Eine Abfrage unter dem alten Namen liefert kein Ergebnis.

Aster TSDB `pp` — Platform-Rohdaten (nur lesend)

Die AI liest nur die von der Platform erfassten Daten. Hier wird nicht geschrieben.

Tabelle	Verwendung
`tm_asset_data_based_second` / `_minute` / `_hour`	Zeitreihe der Anlagensensoren
`tm_tag_point`	Tag-Punkte
`tm_asset_alarm`	Alarm
`tm_kpi_oee_history`	OEE
`tm_kpi_ram_history` · `tm_kpi_ems_history`	RAM · EMS
`tm_monitor_platform_status`	Systemressourcen (CPU · Speicher · Festplatte)

Der Partitionsschlüssel unterscheidet sich je nach Auflösung

second : PRIMARY KEY ((asset_id, date, hour), timestamp)
minute : PRIMARY KEY ((asset_id, date), timestamp)
hour   : PRIMARY KEY (asset_id, timestamp)
kpi    : PRIMARY KEY ((asset_id, day), timestamp)   -- tm_kpi_*_history

Bei der KPI-Historie (tm_kpi_*_history) ist day ein UTC-Datum (yyyymmdd). Ein lokaler Tag erstreckt sich über zwei UTC-Buckets, daher muss der Zeitraum in eine Liste von UTC-Daten aufgelöst und je Bucket gelesen werden. Eine Zeile ist der kumulierte Auftragsstand bis zu diesem Zeitpunkt — Zeilen dürfen nicht addiert werden. Genaue Regeln siehe KPI-Tabelle.

Bei langsamen Abfragen zuerst die Auflösung prüfen

Bei Sekundenauflösung geht die Partitionierung bis auf Anlage · Datum · Uhrzeit. Durchsucht man einen langen Zeitraum in Sekundenauflösung, werden Tausende Partitionen berührt. Für lange Zeiträume _hour verwenden, für kurze, enge Zeiträume _second.

Das vollständige Schema auf Platform-Seite finden Sie unter Platform-Datenbankmodell.

Neo4j · Qdrant — Wissensgraph und Vektoren

Speicher	Inhalt
Neo4j (`plantpulse-neo4j`)	Wissensgraph von LightRAG — aus Dokumenten extrahierte Entitäten·Beziehungen
Qdrant	Embedding-Vektoren der Dokumentenchunks

Der Spiegel des Werksgraphen des Digital Thread liegt in einer anderen Neo4j-Instanz (plantpulse-digital-thread-neo4j). Da dies nicht der Speicher von LightRAG ist, gehört er nicht zu den „vier" unten.

Die Speicher der RAG-Engine (LightRAG) sind auf vier Stellen verteilt. Kennt man nur zwei davon, läuft die Wiederherstellung schief.

Was	Wo	Konfiguration
Vektor	Qdrant	`LIGHTRAG_VECTOR_STORAGE=QdrantVectorDBStorage`
Graph	Neo4j	`LIGHTRAG_GRAPH_STORAGE=Neo4JStorage`
KV-Cache	Lokales JSON im `lightrag-storage` Volume	`LIGHTRAG_KV_STORAGE` nicht konfiguriert — LightRAG-Standardwert (`JsonKVStorage`)
Dokumentenverarbeitungsstatus	`lightrag` DB der Platform-PG	`LIGHTRAG_DOC_STATUS_STORAGE=PGDocStatusStorage`

Dass der KV-Cache als lokales JSON vorliegt, ist bewusst so belassen — für eine einzelne Instanz ausreichend, ohne Abhängigkeit vom Valkey der Platform. Bei Skalierung auf mehrere Instanzen wechselt man auf LIGHTRAG_KV_STORAGE=RedisKVStorage + REDIS_URI.

Werden die vier Speicher «getrennt» wiederhergestellt, gerät der Index durcheinander

Nur der Dokumentenverarbeitungsstatus liegt in PostgreSQL. Stellt man nur PG wieder her und lässt Qdrant·Neo4j leer, geht LightRAG davon aus, dass die Dokumente bereits eingefügt wurden, und fügt sie nicht erneut ein — die Suche liefert dauerhaft leere Ergebnisse. Umgekehrt führt die Wiederherstellung nur von Graph·Vektor zu einem Statusmismatch und doppelter Ingestion.

Beim Zurücksetzen: alle vier auf denselben Zeitpunkt bringen, oder alle vier leeren und aus den Originalen neu einfügen. Die Originale liegen im lightrag-inputs Volume — dieses Volume ist faktisch das Backup, geht auch dieses verloren, gibt es keine Möglichkeit mehr, den Index neu zu erzeugen.

Zu Ontologie-Konzepten siehe Ontologie verstehen.

Übersicht des Backup-Umfangs

Speicher	Wer sichert	Ohne Backup
PostgreSQL `pi` (`co` · `dt`)	Muss von der AI-Seite gesichert werden	Dialog · Incident · Konfiguration sowie das Konnektorregister gehen verloren
PostgreSQL `lightrag` · `rag_ingest`	Muss von der AI-Seite gesichert werden	Der Dokumentenverarbeitungsstatus geht verloren — siehe obige Danger-Box
PostgreSQL `litellm`	AI	Gateway-Schlüssel und Nutzungsverlauf gehen verloren
Aster TSDB `pi`	Muss von der AI-Seite gesichert werden	Features gehen verloren, Analysebildschirme bleiben leer (Neuberechnung möglich, aber langwierig)
Aster TSDB `pp`	Platform-Backup	—
Neo4j · Qdrant	AI	Dokumentenindex geht verloren (aus Originalen neu erzeugbar)
Digital-Thread-Neo4j	AI (`bin/backup.sh` als gesamtes Volume)	Der Spiegel geht verloren (aus der Quelle neu aufbaubar)
`lightrag-storage` Volume	AI	KV-Cache geht verloren (neu erzeugbar)
`lightrag-inputs` Volume	AI — am wichtigsten	Die Originaldokumente gehen verloren, der Index kann nicht neu erzeugt werden

Vorgehensweise siehe Datenbankverwaltung.

PostgreSQL pi.co — Dialog- und Betriebsstatus​

PostgreSQL pi.dt — Register des Digital Thread​

PostgreSQL rag_ingest — Status der Dokumenten-Ingestion​

Aster TSDB pi — Feature Store​

Aster TSDB pp — Platform-Rohdaten (nur lesend)​

Der Partitionsschlüssel unterscheidet sich je nach Auflösung​

Neo4j · Qdrant — Wissensgraph und Vektoren​

Übersicht des Backup-Umfangs​

Verwandte Dokumente​