2.1 データモデルの概念

データモデルは、1件として何を保存し、どの値で識別し、どう変更・検索するかを定める規則です。時系列モデルでは、計測対象、時刻、値の意味を併せて定義します。列名を決める前にこの規則を確認すると、入力と分析結果を一貫して解釈できます。

時系列データを理解する

時系列データは、時間に沿った観測やイベントの記録です。温度計測、約定履歴、サービスエラーログなどが代表例です。一定間隔でもイベント発生時だけでも収集できます。保存順序と発生順序が同じとは限りません。

1行の意味と識別子

温度履歴の1行を「1つのセンサーが特定時刻に測定した値」と定義した場合、センサー識別子、計測時刻、値が必要です。識別子はデータの対象を区別し、時刻は対象の変化を解釈する基準になります。

複数センサーが同じ時刻に測定できるため、時刻だけでは行を一意に識別できません。同じセンサーの同じ時刻のデータも再送されることがあります。重複を許すか、排除するか、別のイベント番号を設けるかを決めてください。TAG の PRIMARY KEY はタグを識別し、関係型テーブルの行キーのように各計測行の名前を一意にするものではありません。重複処理は TAG テーブルの運用で確認します。

値、単位、品質

数値だけでは単位や意味が分かりません。同じ 23.5 でも温度、圧力、電圧は異なります。タグ定義や参照データで単位と計測場所を管理し、1つの時系列で値の意味を一貫させます。

NULL と 0 も区別します。機器が0を計測したことと、計測に失敗して値が不明なことは異なります。必要なら品質や状態を別の列に記録します。未収集の区間には行自体がないこともあり、 NULL の行が存在する場合とも区別する必要があります。

一般的な AVG などの集計は NULL 以外の値に適用されます。欠測をすべて0に置き換えたり、異なる単位を一緒に集計したりすると結果が変わります。対応集計関数の正確な NULL 処理は関数リファレンスを参照してください。

時系列ワークロードの特徴

多くの時系列システムは、新しい行を継続的に入力し、特定対象の時間範囲を検索します。最新値の監視と長期間の統計分析を併用することもあります。これらのパターンが、追記型の入力、範囲検索、ROLLUP を使う理由です。

ただし、過去データが常に不変とは限りません。機器時計の誤り、センサー補正、重複収集で修正が必要になることがあります。最新より古いデータを頻繁に読む業務もあります。実際の入力・検索・修正パターンを測定して設計してください。

テーブルタイプの役割

テーブルタイプ	概念上の役割
TAG	名前と時間・距離軸を持つ計測履歴
LOG	新しい記録を追記し続けるイベントとログ
TRANSACTION	トランザクションと行単位の変更を必要とする業務データ
LOOKUP	メモリに読み込んで参照する永続的な参照データ
VOLATILE	再起動後に再生成できる共有インメモリ状態

履歴と参照データを分けると、全計測行に設備名や場所を繰り返し保存する必要が減ります。ただし、最新の参照データを過去履歴に結合すると、結果にも現在の名前や場所が表示されます。発生時点の情報が必要なら、イベントとともに保存するか、参照データの変更履歴を別途設計します。

関係型業務モデルと時系列モデル

関係型モデルと時系列モデルは相互に排他的ではありません。関係型 DBMS でも時系列を保存し、インデックス・パーティション・集計を利用できます。Machbase もテーブル、SQL、結合、関係型データの変更機能を提供します。製品名ではなく主なワークロードを基準に比較してください。

観点	関係型業務データの例	時系列履歴の例
行の意味	1件の注文の現在の状態	1件のセンサー計測またはイベント
変更パターン	キーで見つけた行の更新・削除	新規レコードの追加と必要範囲の修正・削除
クエリパターン	キー検索、条件検索、業務テーブルの結合	対象・時間範囲の検索、推移、区間統計
整合性要件	複数変更をまとめて確定または取り消す	欠測・重複・遅延入力と参照可能時点を管理
保持設計	業務ライフサイクルと変更履歴	元データの解像度、集計周期、保持期間

LOG・TAG の保存・入力特性を TRANSACTION・LOOKUP・VOLATILE にそのまま適用しないでください。最終的な選択はテーブルタイプの選択とデータ変更ポリシーで確認します。

書き込み中心のワークロードと append-only モデル

append は既存値を上書きせず、新しい行を追加する方式です。例えば設備状態が RUNNING から STOPPED に変わった際にイベントを追加すると、以前の状態と遷移時刻を保持できます。現在状態を直接参照するテーブルと、変更履歴を保存するテーブルを分けて運用することもできます。

テーブルタイプと変更モデル

LOG は追記型の履歴テーブルで、一般的な行 UPDATE をサポートしません。TAG は計測履歴を追加し、対応する条件と Edition の範囲で DATA 値を補正できます。タグ名や時間軸まで任意に変更する一般的な行更新とは異なります。

TRANSACTION は関係型 DML と明示的トランザクションを提供し、LOOKUP・VOLATILE は参照データや状態の変更に使います。すべてのテーブルタイプが同じ変更機能を持つと考えず、データ変更ポリシーを確認してください。

追記型設計は、継続入力と過去行の任意更新を併用する場合の競合を減らせます。ただし DBMS 内部の同期や障害復旧処理がすべてなくなるわけではありません。保存構造だけでロック不要や特定のスループットを保証することはできません。

SQL 入力と SDK Append

SQL INSERT は SQL 文で値を入力し、実行結果を確認する経路です。SDK Append は継続収集のために複数行を転送する入力 API です。バッファリング、転送、エラー確認、終了処理は各 SDK の仕様に従います。

アプリケーションのバッファへ入れた時点、サーバーが処理した時点、障害後も復旧できる時点は異なります。 LOG・TAG の Append は TRANSACTION テーブルの明示的トランザクションで ROLLBACK する対象ではありません。 TRANSACTION への Append のトランザクション参加とエラー処理は、使用する SDK の仕様を確認します。入力確認と再試行はデータの入力とエクスポートを参照してください。

修正、スキーマ変更、保持

誤った LOG イベントは、修正イベントを追記して履歴を残せます。削除して再入力する場合は、 LOG で許される時間ベースの削除範囲と入力順序を先に確認します。特定の1行だけを任意に削除できるとは限りません。TAG の値補正は TAG データ補正の設計に従います。

列の追加・削除と型変更も別の機能です。LOG・TAG のすべてのスキーマ変更が禁止されているわけではなく、タイプと DATA・METADATA 領域によってサポート範囲が異なります。 DDL 構文を確認してから実施します。

元データの追記を続けると保存領域が増えます。元データの保持期間と ROLLUP 統計の目的は別々に定めてください。集計を作成しても元データは削除されません。

時間モデルと _arrival_time

発生時刻と受信時刻

発生時刻は機器が計測した、またはイベントが発生した時刻です。受信時刻は DBMS がレコードを受け取った時刻です。 09:00 の計測値をネットワーク復旧後の09:05に受信すると、差は5分です。計測の推移には発生時刻、収集遅延の分析には両方の時刻の比較が必要です。

時刻の精度、タイムゾーン、時計の正確さも区別します。ナノ秒を表現できても、センサーの時計がナノ秒単位で正確とは限りません。DATETIME 文字列の解釈や表示に使うタイムゾーンはタイムゾーン設定を参照してください。

LOG テーブルの `_arrival_time`

LOG には _arrival_time DATETIME 列が自動追加されます。値を省略する通常の入力ではサーバー受信時刻を記録します。別途発生時刻が必要なら、一般の DATETIME 列を定義します。

CREATE LOG TABLE device_events (
    device_id VARCHAR(20),
    event_time DATETIME,
    status VARCHAR(20)
);

_arrival_time を明示する入力経路もあるため、この列が常に実際の受信時刻を表すとは限りません。明示入力の時刻順序と制約は LOG の時間モデルを確認します。

SELECT device_id, event_time, status
FROM device_events
WHERE _arrival_time >= TO_DATE('2026-07-03 09:00:00', 'YYYY-MM-DD HH24:MI:SS')
  AND _arrival_time <  TO_DATE('2026-07-03 10:00:00', 'YYYY-MM-DD HH24:MI:SS')
ORDER BY _arrival_time;

開始を含み終了を含まない [開始, 終了) の範囲を使うと、連続区間の境界を二重集計する誤りを減らせます。 BETWEEN は両端を含むため、目的に合わせて選びます。LOG の DURATION は _arrival_time を基準に範囲を限定します。

TAG テーブルの BASETIME 列

時間軸 TAG テーブルでは、BASETIME 属性を持つ DATETIME 列へアプリケーションが時刻を入力します。 LOG の自動 _arrival_time 列は使用しません。

CREATE TAG TABLE sensor_values (
    name VARCHAR(128) PRIMARY KEY,
    time DATETIME BASETIME,
    value DOUBLE SUMMARIZED
);

INSERT INTO sensor_values
VALUES ('temp_sensor_01',
        TO_DATE('2026-07-03 08:55:00', 'YYYY-MM-DD HH24:MI:SS'),
        23.1);

この例の name はセンサー、time は計測時刻、value は計測値です。SUMMARIZED は ROLLUP などの統計機能が使用する代表的な数値列を指定します。テーブルを作成するだけで必要なすべての周期の集計が作られるわけではありません。

TAG には時間の代わりに数値軸を使う BASE DISTANCE モデルもあります。距離・位置に沿った計測ではこのモデルを検討しますが、時間軸専用の関数やポリシーをそのまま適用してはいけません。 TAG スキーマで軸別の規則を説明します。

2つの時間モデルの比較

項目	LOG	時間軸 TAG
特殊な時刻列	自動生成される `_arrival_time`	宣言した `BASETIME` 列
入力時刻の意味	通常はサーバー時刻、明示入力時は指定値	アプリケーションが指定する時刻
別の発生時刻	一般の DATETIME 列に保存可能	BASETIME を発生時刻として使用可能
主な設計課題	どのイベントとフィールドを検索するか	どのタグのどの範囲を分析するか

発生時刻が必要なだけで LOG を除外する必要はありません。時刻の意味に加え、タグ構造、検索・集計、更新・削除条件でテーブルを選んでください。LOOKUP・VOLATILE・TRANSACTION の DATETIME は一般列であり、 LOG・TAG の特殊な時間軸機能は自動付与されません。

行の保存順序と結果の表示順序も区別します。順序が重要なら ORDER BY を明示し、同じ時刻の行まで区別する場合は追加のソートキーを指定します。

最終更新日 9月 10, 2026

2.2 ストレージと実行の構造