データベースモデル

プラットフォームがデータをどこに、どのような形で保存するのかを整理したドキュメントです。バックアップの範囲を決定したり、直接照会したり、保存期間を調整する際に参照します。

単一の種類ではありません

プラットフォームはデータの性質に応じて保存先を分ける(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個のテーブルは2つのカテゴリに分かれます。

プレフィックス	個数	意味
`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` — 1 つのタグが 1 つのパーティション
クラスタリング	`timestamp` 降順 — 最新データから読み込むのが標準
デフォルト TTL	`5356800` 秒 = 62日
Compaction	`UnifiedCompactionStrategy` (Cassandra 5.0+)
インデックス	`asset_id` · `opc_id` にSAI(Storage Attached Index)

static カラムがある理由

site_id · asset_id · line_id · area_id · opc_id · tag_name · type は static です。1 つのタグ(=1 つのパーティション)内では値が同じであるため、パーティションごとに 1 回だけ保存されます。すべてのデータポイントで繰り返し保存されないため、容量が大幅に削減されます。

派生テーブル — 事前計算

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

62日より古いデータを検索する場合

Cassandra には存在しません。Iceberg 側を照会してください → 分析レイヤー。

バックアップで見落とされやすい点

3つの保存先は各々がバックアップ対象です。PostgreSQL だけをバックアップして安心する場合がありますが、その場合は時系列データが完全に欠落します。

保存先	欠落した場合
PostgreSQL	設備・タグ定義、ユーザー、ダッシュボードが失われる
Cassandra	最新 62日間のデータが失われる
Iceberg / オブジェクトストレージ	長期履歴が失われる

手順についてはバックアップと復旧を参照してください。

PostgreSQL — マスターと設定​

Cassandra — 時系列とイベント​

コアテーブル — tm_tag_point​

派生テーブル — 事前計算​

Iceberg — 長期保存​

バックアップで見落とされやすい点​

関連ドキュメント​