Datenbankverwaltung

Datenbankkonfiguration

PlantPulse AI verwendet 6 Datenbanken, die jeweils für unterschiedliche Zwecke eingesetzt werden.

Datenbank	Verwendung	Datentyp
PostgreSQL	Relationale Metadaten	Benutzerinformationen, Chat-Verlauf, RAG-Metadaten, Feature Store
Aster TSDB	Zeitreihen-Speicherung	Sensordaten, Copilot-Tasks, Inferenz-Historie
Neo4j (zwei Instanzen)	Graphdaten	LightRAG-Wissensgraph · Fabrikgraph-Spiegel des Digital Thread
Qdrant	Vektorspeicher	Dokument-Embeddings, Anlagen-Feature-Vektoren
Valkey (Redis)	Cache	Sitzungen, temporäre Daten, Such-Cache
RustFS	Objektspeicher	Dokumentdateien, Bilder, Berichte

PostgreSQL

Datenbankliste

Die AI startet kein eigenes PostgreSQL, sondern legt vier DBs innerhalb des PostgreSQL der Platform an und nutzt sie (wenn provision-platform-db.sh nicht existiert, wird es angelegt, existiert es bereits, wird übersprungen — idempotent).

Datenbank	Verwendende Dienste
`pi`	DB der AI-Apps — ein Schema pro App: `co` = AI Chat Web (Benutzer · Chat-Verlauf · Apps · Einstellungen), `dt` = Digital Thread (Connector-Register)
`lightrag`	Dokumentverarbeitungsstatus von LightRAG (`doc_status`)
`rag_ingest`	Status der Dokumenten-Einlese-Pipeline (rag-api). Wenn Zeichnungs- · Videoerfassung aktiviert sind, werden deren Tabellen (`rag_drawing_` · `rag_media_`) hier ebenfalls beim Start angelegt
`litellm`	Schlüssel · Nutzung des LiteLLM-Gateways

Das Zugangskonto ist das Konto des Platform-PG (PP_PG_USER) — es gibt kein separates AI-Konto. Auch die beiden Schemata von pi werden mit diesem Konto verbunden. Die Tabelle wird nicht in public abgelegt.

Beim Upgrade von 2026.09 oder früher — `ch` wird nach `pi.co` verschoben

Bei 2026.09 oder früher lag die Copilot-Tabelle in public der DB ch. Bei 2026.10 läuft beim Start bin/migrate-pg-ch-to-pi.sh vor compose und verschiebt diese — da install · up · update · compose-up alle derselben Reihenfolge folgen, muss dies nicht gesondert aufgerufen werden.

Copilot- und Digital-Thread-Container stoppen.
Verbleibende Sitzungen in ch bereinigen — es werden nur Sitzungen des an ch angehängten App-Kontos (PP_PG_USER) beendet.
In einer einzigen Transaktion werden die Objekte aus public in das neue Schema co verschoben.
ALTER DATABASE ch RENAME TO pi.

Zustand	Aktion
Nur `pi` vorhanden · beide nicht vorhanden	Keine Aktion erforderlich
Nur `ch` vorhanden	Migration gemäß obiger Reihenfolge
Sowohl `ch` als auch `pi` vorhanden	Wird abgelehnt, nichts wird geändert
Objekte sowohl in `public` als auch in `co` von `ch` vorhanden	Ablehnung (Spuren einer manuell halb durchgeführten Migration)

cd /opt/kopens/plantpulse-ai-docker
bin/migrate-pg-ch-to-pi.sh --check      # 미리 보기 — 아무것도 바꾸지 않습니다
bin/migrate-pg-ch-to-pi.sh --rollback   # 되돌리기 — pi.co → ch.public, 이름을 ch 로

Das Migrationsskript erstellt keinen Dump

Erstellen Sie vor dem Upgrade einmalig einen Dump von ch nach pg_dump. Plattenplatz und Aufbewahrung des Platform-PG liegen in der Verantwortung der Plattform und werden von diesem Skript nicht übernommen. Nach einem Rollback muss mit dem compose und dem Copilot-Image der vorherigen Version gestartet werden — wird mit dem neuen compose gestartet, wird sofort erneut migriert.

Verwaltung

# PostgreSQL 접속 — 코파일럿 스키마
psql -h <플랫폼 PG 호스트> -U <PP_PG_USER> -d pi -c 'SET search_path TO co' -c '\dt'

# 디지털 스레드 스키마
psql -h <플랫폼 PG 호스트> -U <PP_PG_USER> -d pi -c '\dt dt.*'

# 데이터베이스 목록 확인
psql -h <플랫폼 PG 호스트> -U <PP_PG_USER> -c '\l'

Aster TSDB

Keyspaces

Keyspace	Verwendung
`pi`	PlantPulse AI Haupt-Keyspace (Copilot-Tasks, Inferenz-Historie)

Verwaltung

# Cassandra CQL 접속
cqlsh 127.0.0.1 9042 -u cassandra -p cassandra

# 키스페이스 목록
DESCRIBE KEYSPACES;

# 테이블 목록
USE pi;
DESCRIBE TABLES;

info

Die Aster-TSDB-Keyspaces werden beim ersten Start automatisch durch das Skript db/cassandra/support/keyspace-create.sh erstellt.

Neo4j

Ab 2026.10 werden zwei Neo4j-Instanzen gestartet. Es ist dasselbe Image, und auch die Konten (PI_NEO4J_USER · PI_NEO4J_PASSWORD) sind gleich, aber Inhalt und Zugänglichkeit unterscheiden sich.

Container	Inhalt	Volume	Host-Port
`plantpulse-neo4j`	LightRAG-Wissensgraph	`pi-neo4j-data`	7474 · 7687
`plantpulse-digital-thread-neo4j`	Fabrikgraph-Spiegel des Digital Thread (`Dt*`) — nur Referenz, kein Volltext	`pi-digital-thread-neo4j-data`	keiner

Da Neo4j Community weder mehrere DBs anlegen noch Berechtigungen nach Rollen trennen kann, wurden die beiden Dienste durch separate Instanzen strikt getrennt. Beim Digital-Thread-Teil ist nur die Digital-Thread-API innerhalb des compose-Netzwerks angebunden, und es gilt eine Speicherobergrenze (Heap 512 MB · Page Cache 256 MB).

Das Passwort wird von bin/passwd.sh für beide Instanzen gemeinsam geändert

Da es sich um ein einziges Konto handelt, ändern Sie nicht nur eine Seite → Passwort · API-Schlüssel ändern

Zugangsdaten — `plantpulse-neo4j`

Element	Wert
Browser URL	http://<ServerIP>:7474
Bolt URI	bolt://127.0.0.1:7687
Benutzer	neo4j
Passwort	neo4j123

Verwaltung

Im Neo4j Browser (http://<ServerIP>:7474) wird der Graph mit Cypher-Abfragen verwaltet:

// 노드 타입별 카운트
MATCH (n) RETURN labels(n), count(n) ORDER BY count(n) DESC;

// 관계 타입별 카운트
MATCH ()-[r]->() RETURN type(r), count(r) ORDER BY count(r) DESC;

Digital-Thread-Seite — `plantpulse-digital-thread-neo4j`

Da der Port nicht offen ist, kann über den Browser nicht zugegriffen werden. Der Status wird in der Verwaltungskonsole im Bildschirm Digital Thread → Graph-Spiegel (Neo4j-Sonde · Anzahl der Knoten pro Label) eingesehen. Der Spiegel ist eine Kopie, die aus der Quelle (Platform-Register · Ereignisse) neu erstellt werden kann → Digital Thread

Qdrant

Zugangsdaten

Element	Wert
REST API	http://127.0.0.1:6333
Dashboard	http://127.0.0.1:6333/dashboard
API Key	qdrant-key-123

Collections

Collection	Verwendung
(automatisch von LightRAG erstellt)	RAG-Dokumentvektoren (verwaltet von LightRAG)

RustFS

Zugangsdaten

Element	Wert
API	http://127.0.0.1:9000
Console	http://127.0.0.1:9001
Access Key	minio
Secret Key	minio123!

Buckets

Bucket Verwendung

plantpulse-rag Ein einzelner Objektspeicher von rag-api. Unterscheidung per Präfix — manual/ für in der Verwaltungskonsole manuell hochgeladene Dokumentoriginale, drawings/ für Zeichnungsstruktur und Seitenvorschauen (wenn Zeichnungserfassung aktiviert ist), media/ für Video-/Audio-Wiedergabe und Transkripte (wenn Videoerfassung aktiviert ist), migration/ als Markierung für abgeschlossene Migration des alten Buckets. Der Bucket-Name ist der compose-Standardwert; nur wenn zwei AI-Installationen dieselbe Plattform gemeinsam nutzen, erhält die zweite Installation über die Host-Env-Variable RAG_S3_BUCKET einen abweichenden Namen → Umgebungsvariablen konfigurieren

Bucket	Verwendung
`plantpulse-rag`	Ein einzelner Objektspeicher von rag-api. Unterscheidung per Präfix — `manual/` für in der Verwaltungskonsole manuell hochgeladene Dokumentoriginale, `drawings/` für Zeichnungsstruktur und Seitenvorschauen (wenn Zeichnungserfassung aktiviert ist), `media/` für Video-/Audio-Wiedergabe und Transkripte (wenn Videoerfassung aktiviert ist), `migration/` als Markierung für abgeschlossene Migration des alten Buckets. Der Bucket-Name ist der compose-Standardwert; nur wenn zwei AI-Installationen dieselbe Plattform gemeinsam nutzen, erhält die zweite Installation über die Host-Env-Variable `RAG_S3_BUCKET` einen abweichenden Namen → Umgebungsvariablen konfigurieren

rag-manual-docs vor 2026.10 wird automatisch migriert

Frühere Versionen legten manuell hochgeladene Originale im Bucket rag-manual-docs ab. Das rag-api von 2026.10 kopiert beim Start im Hintergrund diese Objekte nach manual/ unter plantpulse-rag. Existieren sie am neuen Ort bereits, werden sie nicht überschrieben, und der alte Bucket wird nur lesend verwendet, sodass auch bei einem Rollback auf das alte Image weiterhin gelesen werden kann. Der Fortschritt kann unter dem Eintrag object_store_migration von rag-api /api/v1/config eingesehen werden.

Pfade zur Datenspeicherung

Der lokale Zustand des AI-Stacks liegt in benannten Docker-Volumes, nicht in Host-Verzeichnissen. Versuchen Sie nicht, sie über Host-Pfade zu finden — betrachten Sie sie über docker volume inspect.

Volume	Inhalt	Bei Verlust
`pi-lightrag-inputs`	Hochgeladene Originaldokumente	Keine Möglichkeit, den Index zu regenerieren
`pi-lightrag-storage`	LightRAG-KV-Cache (lokales JSON)	Kann regeneriert werden
`pi-qdrant-data`	Dokument-Embedding-Vektoren	Kann aus den Originalen regeneriert werden
`pi-neo4j-data`	LightRAG-Wissensgraph	Kann aus den Originalen regeneriert werden
`pi-digital-thread-neo4j-data`	Fabrikgraph-Spiegel des Digital Thread	Kann aus der Quelle wiederhergestellt werden — da Platform-Ereignisse jedoch erneut gelesen werden müssen, ist die Wiederherstellung deutlich schneller
`pi-ttm-tuned-models`	Pro Installation trainierte Zeitreihenmodelle basierend auf Vor-Ort-Daten	Kann ohne die jeweiligen Vor-Ort-Daten nicht neu erstellt werden
`pi-pp-proxy-certs`	TLS-Zertifikate des Proxys	Bei echten, vom Kunden eingebrachten Zertifikaten müssen diese erneut beschafft werden
`pi-phoenix-data`	LLM-Aufruf-Traces	Vergangene Traces gehen verloren
`pi-registry-data`	Lokale Image-Registry (nur bei Knoten mit aktiviertem Profil `registry`)	Images müssen erneut eingespielt werden
`pi-asr-audio`	Audio-Bibliothek, die von der Transkript-Bereitstellung gelesen wird (nur bei Installationen mit aktivierter Video-/Audioerfassung)	Es geht nichts verloren — `plantpulse-asr-audio` schreibt sie bei jedem Start neu

Was `bin/backup.sh` sichert

Es werden alle in der compose-Datei deklarierten Volumes gesichert — es wird keine separate Liste geführt. Ausgenommen sind nur die regenerierbaren Logs und Caches (copliot-web-logs · insight-api-logs · llm-cache · emb-cache · rerank-cache · asr-cache) sowie die bei jedem Start neu erstellte Audio-Bibliothek für Transkripte (asr-audio). registry-data existiert nur bei Knoten mit aktiviertem Profil — ist es vorhanden, wird es gesichert, andernfalls übersprungen.

cd /opt/kopens/plantpulse-ai-docker/bin
./backup.sh --list                  # 볼륨마다 backup · optional · exclude 판정만 찍는다
./backup.sh                         # 전부 → /data1/pp-backup/YYYYMMDD/<볼륨>.tar.gz
COMPONENT=neo4j-data ./backup.sh    # 하나만

Parameter	Standardwert	Bedeutung
`BACKUP_ROOT`	`/data1/pp-backup`	Ort der Sicherung
`BACKUP_RETENTION_DAYS`	`30`	Löscht Datumsverzeichnisse, die älter sind — nur wenn der jeweilige Durchlauf vollständig erfolgreich war

Früher wurden nur vier Volumes gesichert

Das backup.sh vor 2026.09 sicherte nur vier manuell angegebene Volumes (neo4j-data · qdrant-data · lightrag-storage · lightrag-inputs), das Volume für TLS-Zertifikate fehlte dabei. Jetzt wird die Liste aus compose entnommen, sodass neu hinzukommende Volumes standardmäßig gesichert werden.

Im laufenden Betrieb erstellte Sicherungen sind möglicherweise nicht vollständig konsistent

Es kann sich um eine Kopie handeln, die während eines Schreibvorgangs erstellt wurde. Wenn eine konsistente Sicherung benötigt wird, etwa unmittelbar vor einem Upgrade, fahren Sie zuerst mit bin/compose-down.sh herunter und führen Sie die Sicherung dann aus. Auch die Wiederherstellung erfolgt bei heruntergefahrenem compose (Beispiele finden sich im Vorspann von bin/backup.sh).

PostgreSQL · Aster TSDB · Redis · RustFS gehören zur Plattform, daher werden sie von diesem Skript nicht gesichert — hierfür gilt das Backup-Verfahren der Plattform.

Empfehlungen zur Datensicherung

Ziel	Methode	Intervall
PostgreSQL	`pg_dump`	1× täglich
Neo4j	`neo4j-admin dump`	1× täglich
RustFS	`rc mirror`	1× täglich
Qdrant	Snapshot API	1× wöchentlich
`/etc/kopens/plantpulse-ai.env`	Dateikopie — 🔴 `PI_LITELLM_SALT_KEY` befindet sich hier	Bei Änderung
Lokale AI-Volumes	`bin/backup.sh` (siehe oben)	1× täglich

Datenbankkonfiguration​

PostgreSQL​

Datenbankliste​

Beim Upgrade von 2026.09 oder früher — ch wird nach pi.co verschoben​

Verwaltung​

Aster TSDB​

Keyspaces​

Verwaltung​

Neo4j​

Zugangsdaten — plantpulse-neo4j​

Verwaltung​

Digital-Thread-Seite — plantpulse-digital-thread-neo4j​

Qdrant​

Zugangsdaten​

Collections​

RustFS​

Zugangsdaten​

Buckets​

Pfade zur Datenspeicherung​

Was bin/backup.sh sichert​

Empfehlungen zur Datensicherung​

Datenbankkonfiguration

PostgreSQL

Datenbankliste

Beim Upgrade von 2026.09 oder früher — `ch` wird nach `pi.co` verschoben

Verwaltung

Aster TSDB

Keyspaces

Verwaltung

Neo4j

Zugangsdaten — `plantpulse-neo4j`

Verwaltung

Digital-Thread-Seite — `plantpulse-digital-thread-neo4j`

Qdrant

Zugangsdaten

Collections

RustFS

Zugangsdaten

Buckets

Pfade zur Datenspeicherung

Was `bin/backup.sh` sichert

Empfehlungen zur Datensicherung