SQL ビューから作成されたグラフの概要

このドキュメントでは、SQL ビューを使用してグラフを作成するメリットについて説明します。このドキュメントでは、ビューを使用してグラフを作成するメリット、要件、考慮事項について説明します。これにより、グラフの作成に テーブルとビューのどちらを使用するかを判断できます。

ビューからグラフを作成する方法の詳細については、SQL ビューからプロパティ グラフを作成するをご覧ください。

テーブルではなくビューでグラフを作成するメリット

SQL ビューは、SQL クエリによって定義される仮想テーブルです。Spanner では、ビューを参照するクエリが実行されるたびに、ビューを定義するクエリが実行されます。Spanner ビューは、ビューを定義するクエリの結果をデータ ストレージに実際のテーブルとして保存しないため、マテリアライズド ビューではありません。詳細については、ビューの概要をご覧ください。SQL ビューからグラフ要素を作成できますが、グラフをクエリするビューは作成できません。

ビューは、テーブルとグラフ スキーマ間の抽象化レイヤとして、テーブルを使用してグラフを作成する場合には利用できないいくつかの利点を提供します。

ビューを使用してグラフを作成するための要件

ビューを使用してグラフ要素を作成する場合は、次の要件を満たす必要があります。

グラフ要素を指定する場合は KEY 句を使用する

ビューを使用してノード要素またはエッジ要素を作成する場合は、グラフ要素を一意に識別する列を明示的に定義する必要があります。これを行うには、ノードまたはエッジ要素の定義で KEY 句を使用します。グラフ要素の作成時に KEY 句を使用する方法については、このドキュメントと SQL ビューから Spanner Graph を作成するのコード例をご覧ください。

ノードとエッジの一意性を保証するビューを使用する

ノードテーブルまたはエッジテーブルを定義するビューは、ノードとエッジが一意であることを保証するために、次のいずれかのパターンに従う必要があります。

  • パターン 1: ビューが単一のテーブルの主キーを使用している。

  • パターン 2: ビューで GROUP BY 句または SELECT DISTINCT 句を使用している。

これらのパターンと組み合わせて、WHERE、HAVING、ORDER BY、LIMIT、TABLESAMPLE などの他の SQL 演算子を使用できます。これらの演算子は結果をフィルタリングまたは並べ替えますが、パターンが提供する基盤となる一意性の保証は変更しません。

パターン 1: 単一のテーブルの主キーを使用する

このパターンでは、ビューは単一のテーブルから選択し、グラフ定義の KEY 句はベーステーブルの主キー列と一致します。このため、ビューによって生成される各ノードまたはエッジ行は一意です。

たとえば、次の例では、Account テーブルから行のサブセットを選択します。グラフ KEY(account_id) は Account テーブルの主キーと一致するため、ビューによって生成される各行は一意になります。

-- Table has PRIMARY KEY(account_id).
CREATE TABLE Account (
  account_id INT64 NOT NULL,
  customer_id INT64 NOT NULL,
  account_type STRING(MAX),
  balance INT64
) PRIMARY KEY(account_id);

-- Pattern 1: View uses the primary key from a single table.
CREATE VIEW SavingAccount
  SQL SECURITY INVOKER AS
    SELECT accnt.account_id, accnt.customer_id, accnt.balance
    FROM Account accnt
    WHERE accnt.account_type = 'saving';

CREATE PROPERTY GRAPH SavingAccountGraph
  NODE TABLES (
    -- The element KEY(account_id) matches the table's primary key.
    SavingAccount KEY(account_id)
  );

パターン 2: GROUP BY 句または SELECT DISTINCT 句を使用する

このパターンでは、ビューのクエリで GROUP BY 句または SELECT DISTINCT 句を使用します。KEY 句の列は、これらの句が一意性を定義するために使用する列と一致する必要があります。

  • GROUP BY の場合: KEY 句の列は、GROUP BY 句のすべての列と一致する必要があります。

  • SELECT DISTINCT の場合: KEY 句の列は、SELECT DISTINCT リストの列と一致する必要があります。

GROUP BY を使用する場合:

CREATE TABLE Customer (
  customer_id INT64,
  name STRING(MAX)
) PRIMARY KEY (customer_id);

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW CustomerOrder
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      ANY_VALUE(c.customer_id) AS customer_id,
      ANY_VALUE(c.name) AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id
    GROUP BY s.order_id;

CREATE PROPERTY GRAPH OrderGraph
  NODE TABLES (
    -- The KEY(order_id) matches the GROUP BY column in view definition.
    CustomerOrder KEY(order_id)
  );

SELECT DISTINCT を使用する場合:

CREATE TABLE SaleOrder (
  order_id INT64,
  customer_id INT64,
  amount INT64
) PRIMARY KEY (order_id);

CREATE VIEW KeyCustomer SQL SECURITY INVOKER AS
  SELECT DISTINCT s.customer_id, s.amount
  FROM SaleOrder s
  WHERE s.amount > 1000;

CREATE PROPERTY GRAPH KeyCustomersGraph
  NODE TABLES (
    -- The KEY(customer_id, amount) matches the DISTINCT columns.
    KeyCustomer KEY(customer_id, amount)
  );

ビューを使用する際の考慮事項

ビューを使用してグラフ要素を定義する場合は、次のことを考慮して、効果的なグラフを設計して実装してください。

プロパティ グラフのクエリ パフォーマンス

データ変換を行うビュー（GROUP BY、UNNEST、JOIN オペレーションなど）でグラフ要素を定義する場合は、ユースケースのクエリ パフォーマンスを慎重に評価してください。Spanner は、クエリが要素パターン マッチングを実行するたびに、ビューのクエリ定義を実行します。

グラフ スキーマの最適化

ビューを使用してグラフ要素を定義する場合、テーブルを使用してグラフ要素を定義する場合よりも、グラフ スキーマの最適化の効果が低くなることがあります。

単一のテーブルの主キーを投影するビュー

ビューが単一のベーステーブルからのプロジェクションである場合、その基盤となるテーブルに対する最適化はグラフクエリでも有効です。たとえば、次の手法をベーステーブルに適用すると、そのようなビューで定義されたグラフ要素に同様のパフォーマンス上のメリットが得られます。

GROUP BY 句または DISTINCT 句で定義されたビュー

GROUP BY、SELECT DISTINCT、その他の複雑な変換などの集計を実行するビューは、基盤となるテーブル構造との直接的な関係を失います。このため、ベーステーブルのスキーマの最適化によって、ビューで動作するグラフクエリに同じパフォーマンス上のメリットが得られない場合があります。ビューで複雑な集計を行う場合は、ユースケースのクエリ パフォーマンスを慎重に評価してください。

ビューベースのグラフによるデータの変更

ビューはマテリアライズされません。つまり、ビューを定義するクエリの結果をデータ ストレージのテーブルとして保存せず、読み取り専用です。このため、ビューから作成されたグラフでノードまたはエッジを挿入、更新、削除するには、ビューの作成に使用されたテーブルのデータを変更します。

データ整合性を確保するためのグラフ エラー処理

ビューを使用してグラフ要素を定義する場合は、基盤となるベーステーブルでデータ整合性（データ型の適用など）を適用します。そうしないと、ベーステーブルのデータが無効になり、ビューベースのグラフに対するクエリが実行時に失敗する可能性があります。

たとえば、スキーマレスから形式化されたグラフに移行する場合は、CHECK 制約を使用して、ベーステーブル（GraphNode と GraphEdge）のデータを検証します。次のコードは、JSON プロパティ内でこれらの制約を適用して、ソースでのデータの完全性を確保し、実行時のクエリエラーを防ぎます。

-- Enforce that the 'name' property exists for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT NameMustExistForPersonConstraint
CHECK (IF(label = 'person', properties.name IS NOT NULL, TRUE));

-- Enforce that the 'name' property is a string for nodes with the 'person' label.
ALTER TABLE GraphNode
ADD CONSTRAINT PersonNameMustBeStringTypeConstraint
CHECK (IF(label = 'person', JSON_TYPE(properties.name) = 'string', TRUE));

次のステップ