データベースモデル
AI スタックがどこに、どんな形でデータを保管するかを整理した文書です。ストレージは4つあり、 それぞれ役割が異なります。運用手順はデータベース管理を参照してください。
PostgreSQL・Cassandra はPlantPulse プラットフォーム インストール を共有しています。AI スタックが独自の DB を起動しません。そのため「AI バックアップ」と「プラットフォーム バックアップ」が重なります — どちらが何を 受けるのかを明確にしておかないと、両方の間に抜ける区間が生じます。
| ストレージ | 所有 | 内容 |
|---|---|---|
PostgreSQL ch | AI（プラットフォーム PG 内の独立 DB） | チャット・インシデント・設定・MCP |
Cassandra pi | AI | フィーチャストア・異常検知出力物 |
Cassandra pp | プラットフォーム（読み取り専用） | ソースセンサ・アラーム・OEE |
| Neo4j | AI | オントロジー知識グラフ |
| Qdrant | AI | ドキュメント埋め込みベクトル |
PostgreSQL ch — 対話と運用状態
プラットフォーム PostgreSQL 内の独立したデータベース ch です
（jdbc:postgresql://<platform-host>:5432/ch）。
| グループ | テーブル |
|---|---|
| 対話 | chats · chat_messages · prompts · prompt_history |
| ユーザー | users · user_roles · employees · web_push_subscription |
| インシデント | incident · incident_event · assignees |
| 異常検知運用 | anomaly_mute · hourly_anomaly · asset_tag_profile |
| MCP | mcp_server · mcp_tool_call_log · mcp_tool_pref |
| RAG 連携 | rag_asset_card · rag_asset_doc_sync · rag_sync_run |
| 設定 | config · config_audit_log · metadata |
2026-07 改編前は Cassandra にもチャット履歴がありました。現在は**chat_messages
単一情報源**です。古いドキュメントを見て Cassandra から探さないでください。
Cassandra pi — フィーチャストア
時系列インサイトサービスが所有・生成する 12 個のテーブルです。プレフィックスは tsi_ です。
| グループ | テーブル |
|---|---|
| フィーチャ | tsi_tag_feature_hourly · tsi_tag_feature_daily · tsi_asset_feature_hourly · tsi_asset_feature_daily |
| コンテキスト・プロファイル | tsi_asset_context_daily · tsi_asset_profile |
| 異常・故障 | tsi_anomaly_embedding · tsi_failure_signature · tsi_precursor_alert |
| パイプライン | tsi_pipeline_status · tsi_pipeline_history · tsi_backfill_status |
テーブルはサービス起動時にべき等に生成されます。ただしキースペース pi 自体はアプリが作成しません — インストール スクリプト（provision-platform-db.sh）の担当です。
管理コンソールの異常検知・予測画面はすべてこれらのテーブルを読みます。結果が空なら、モデルではなく まずパイプラインを確認してください → 管理コンソールのPipeline Status・ Run History（AI 管理コンソール）。
pp.ti_* はありません2026-07-30 に pp キースペースから pi に移動し、古いテーブルは DROP しました。
古い名前で照会しても見つかりません。
Cassandra pp — プラットフォーム ソース（読み取り専用）
AI はプラットフォームが収集したデータを読み取るだけです。ここに書き込みません。
| テーブル | 用途 |
|---|---|
tm_asset_data_based_second / _minute / _hour | 設備センサ時系列 |
tm_tag_point | タグポイント |
tm_asset_alarm | アラーム |
tm_asset_oee_history | OEE |
tm_asset_ram · tm_asset_ems_history | RAM · EMS |
tm_monitor_platform_status | システムリソース（CPU・メモリ・ディスク） |
パーティションキーは解像度ごとに異なります
second : PRIMARY KEY ((asset_id, date, hour), timestamp)
minute : PRIMARY KEY ((asset_id, date), timestamp)
hour : PRIMARY KEY (asset_id, timestamp)
秒単位は設備・日付・時刻までパーティションに含まれます。長期間を秒単位で走査するとパーティションを
数千個タッチします。広い期間は _hour を、狭い期間だけ _second で表示してください。
プラットフォーム側の全スキーマはプラットフォーム データベースモデル にあります。
Neo4j · Qdrant — 知識グラフとベクトル
| ストレージ | 内容 |
|---|---|
| Neo4j | オントロジー — 設備・プロセス・ドキュメントの関係グラフ |
| Qdrant | ドキュメントチャンクの埋め込みベクトル |
RAG エンジン（LightRAG）はグラフは Neo4j、ベクトルは Qdrant に保存するよう構成されています
（LIGHTRAG_GRAPH_STORAGE=Neo4JStorage、LIGHTRAG_VECTOR_STORAGE=QdrantVectorDBStorage）。
この2つは原本ドキュメントから生成される派生物です。バックアップがないと、原本ファイルを再度アップロードして インデックスを作り直すしか復旧方法がありません — 原本ファイルの保管が実質的なバックアップになります。
オントロジーの概念はオントロジーを理解するを参照してください。
バックアップ範囲の整理
| ストレージ | 誰が担当するか | 失われた場合 |
|---|---|---|
PostgreSQL ch | AI 側が担当 | 対話・インシデント・設定が消える |
Cassandra pi | AI 側が担当 | フィーチャが消えて分析画面が空になる（再計算は可能だが時間がかかる） |
Cassandra pp | プラットフォーム バックアップ | — |
| Neo4j · Qdrant | AI | ドキュメント インデックスが消える（原本から再生成可能） |
手順はデータベース管理を参照してください。
関連ドキュメント
- データベース管理 — アクセス・点検・運用
- AI 管理コンソール — パイプラインステータス確認
- サービスポートマップ
- プラットフォーム データベースモデル