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

クエリ時間は SQL 文の長さだけでは決まりません。読み出すデータ量、条件による範囲の絞り込み、 ソート・結合・集計に必要な処理が重要です。この節では、ストレージ、インデックス、キャッシュが それぞれどのコストを削減するかを説明します。

Machbase アーキテクチャの概要

ユーザーは machsql または SDK で入力・クエリ要求を送ります。サーバーは SQL 構文、オブジェクト、 権限を確認し、実行方法を決め、保存データにアクセスして結果を返します。保存・実行方式は テーブルタイプと Edition によって異なります。

Standard Edition の構造

Standard Edition は単一のデータベースサーバーで SQL 処理とデータ保存を行います。LOG・TAG の 時系列入力に加え、TRANSACTION の関係型データ変更、LOOKUP・VOLATILE の参照データや状態管理も、 各テーブルの特性に合った経路で処理します。

クライアント: machsql または SDK
          │ 入力・クエリ要求
          ▼
Machbase DBMS サーバー
  SQL 解析と実行計画
  テーブル別ストレージ・インデックスアクセス
  メモリバッファとバックグラウンド処理
          │
          ▼
テーブルタイプに応じた保存データ

この図は役割を示す概念図です。すべての要求が同じ保存経路を通ることや、API 呼び出し直後に ディスクへ書き込まれることを意味しません。

Cluster Edition の構造

Cluster Edition は複数ノードで役割を分担します。通常のアプリケーション SQL 接続は Broker を経由し、 Warehouse が時系列データを保存してクエリを実行します。Coordinator はクラスターメタデータと ノード状態、Lookup は参照データ処理、Deployer はデプロイとノード管理を担当します。

複数グループへの分散はスループットと容量を分担するため、同一グループ内の複製は障害に備えるためです。 ノードを追加しても、すべてのクエリが同じ比率で高速化したり、すべての障害を自動回復できたりするわけではありません。

構成別の機能差は Edition の概念、実際のデプロイと障害対応は Cluster のインストールと Cluster の運用で確認します。

入力とクエリの流れ

入力は、対象テーブル・列の確認、値の変換と検証、データの転送・保存という段階で考えられます。 SQL と Append API は処理結果の確認方法が異なるため、アプリケーションは選択した経路の エラー処理と完了条件に従います。

クエリは、SQL 解析と実行計画の作成、対象データへのアクセス、条件評価と集計・結合・ソート、 結果の返却という処理で構成されます。常に同じ順序でデータを処理するわけではなく、 実際の実行計画によってアクセス順序は変わります。

列指向ストレージと圧縮

行指向と列指向

行指向ストレージは同じ行の値をまとめて扱い、列指向ストレージは同じ列の値をまとめて扱います。 次の図は両者の概念を比較する例で、実際のファイル配置そのものではありません。

論理的な行:
  (時刻1, センサーA, 23.1)
  (時刻2, センサーA, 23.5)
  (時刻3, センサーB, 18.0)

行指向:  [時刻1, センサーA, 23.1] [時刻2, センサーA, 23.5] ...
列指向:  [時刻1, 時刻2, 時刻3] [センサーA, センサーA, センサーB] [23.1, 23.5, 18.0]

Machbase の LOG・TAG 時系列ストレージは、列単位のアクセスと圧縮を利用します。多数の行から 一部の列だけを読む分析では、読み出すデータ量を削減できます。ただし温度平均のクエリでも、 センサー・時刻条件があれば、その評価に必要なデータも読みます。

行指向システムもインデックスやパーティションで必要な範囲だけを読めます。行指向は常に全行を読み、 列指向は常に速いと決めつけず、読む行数・列数とアクセス経路を確認してください。TRANSACTION の 関係型ストレージや LOOKUP・VOLATILE のメモリ特性も、LOG・TAG と同じ構造として解釈してはいけません。

圧縮が効果的な条件

同じ列には同じ型の値が集まり、センサー値や時刻には繰り返しや類似パターンが現れることがあります。 これらは圧縮に有利です。一方、ノイズの大きな値、不規則な文字列、入力順序が混在するデータでは 結果が異なる場合があります。

時系列の時刻は必ずしも単調増加しません。遅れて到着する計測値や複数収集元の入力が混在するためです。 特定の圧縮方式や圧縮率を前提にせず、型、値の分布、入力順序、設定に応じて実際の圧縮率と性能を測定します。

パーティションと読み出し範囲

パーティションはデータを管理可能な部分に分割する単位です。検索条件と保存された範囲情報を使って 無関係な部分を読み飛ばすと、読み出しを削減できます。これをパーティションプルーニング （partition pruning）と呼びます。

LOG・TAG の保存単位は、ユーザーが指定する1日・1か月と一致するとは限りません。タグ・軸の条件、 データ分布、テーブル別の保存構造で実際のアクセス範囲は変わります。時間条件があるだけで 必要なデータしか読まないと判断せず、実行計画と測定結果を確認します。

インデックスの基本原理

インデックスは条件に一致するデータを見つけるアクセス経路です。対象が全体の一部なら有効ですが、 大半の行を読む集計では別の経路が有利な場合があります。インデックスには保存領域と、 入力・変更時の維持コストも必要です。

「全センサーの1か月平均」と「センサー A の直近1分の値」では、読むデータの比率が異なります。 同じテーブルでも同じ性能は期待できません。結合では各入力の行数と結合条件も重要です。

対応インデックスと制約はスキーマオブジェクトの定義、 測定と調整はインデックスのチューニングで確認します。

キャッシュと実行計画

SQL の実行過程

サーバーは SQL 構文、型、オブジェクトを確認し、条件とインデックスなどから実行可能なアクセス経路を 決めてデータを処理します。実行計画はその処理方法を表します。計画を作るコストと、 計画に従ってデータを読むコストは異なります。

実行計画の再利用と PVO Cache

PVO Statement Cache は、再利用できる SQL の解析・検証・最適化結果と実行計画を再利用し、 準備処理の繰り返しを削減します。結果の行を保存するキャッシュではないため、計画を再利用しても データの読み出しと条件評価は必要です。

Min-Max Cache のように保存データの範囲情報を使うキャッシュは、読み出し対象を減らすためのものです。 実行計画キャッシュとデータアクセス用キャッシュを混同しないでください。どのキャッシュを増やすかは、 ヒット率とメモリ使用量を確認して判断します。

EXPLAIN による実行計画の確認

次の例は、データモデルの概念で作成した sensor_values テーブルを使用します。

EXPLAIN SELECT AVG(value)
FROM sensor_values
WHERE name = 'temp_sensor_01'
  AND time >= TO_DATE('2026-07-01', 'YYYY-MM-DD')
  AND time <  TO_DATE('2026-07-03', 'YYYY-MM-DD');

実行計画でデータアクセスと条件適用を確認します。計画があるだけでは実際の応答時間やディスク読み出し量は 分からないため、代表データで実行時間も測定します。キャッシュが空の初回実行と再利用時の条件を 区別すると、結果を解釈しやすくなります。

PVO Cache のヒット・削除統計は V$PVO_CACHE_STAT、キャッシュ済み SQL は V$PVO_CACHE_LIST で 確認します。設定と診断はキャッシュとメモリのチューニング を参照してください。