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));

다음 단계