Visão geral dos gráficos criados com visualizações SQL

Use este documento para saber mais sobre os benefícios de usar visualizações SQL para criar um gráfico. Este documento inclui benefícios da criação de gráficos com visualizações, requisitos, e considerações para ajudar você a decidir se deve usar tabelas ou visualizações para criar um gráfico.

Para detalhes sobre como criar um gráfico com visualizações, consulte Criar um gráfico de propriedades com visualizações SQL.

Benefícios de criar gráficos com visualizações em vez de tabelas

Uma visualização SQL é uma tabela virtual definida por uma consulta SQL. No Spanner, a consulta que define uma visualização é executada sempre que uma consulta que se refere à visualização é executada. As visualizações do Spanner não são materializadas porque não armazenam os resultados da consulta que define a visualização como uma tabela real no armazenamento de dados. Para mais informações, consulte Visão geral das visualizações. É possível criar elementos de gráfico com visualizações SQL, mas não é possível criar uma visualização que consulte um gráfico.

As visualizações oferecem várias vantagens como uma camada de abstração entre tabelas e um esquema de gráfico que não estão disponíveis quando você usa tabelas para criar um gráfico.

Requisitos para usar visualizações para criar gráficos

É necessário seguir estes requisitos ao usar visualizações para criar elementos de gráfico:

Use a cláusula KEY ao especificar um elemento de gráfico

É necessário definir explicitamente as colunas que identificam exclusivamente o elemento de gráfico ao usar visualizações para criar um nó ou um elemento de aresta. Para fazer isso, use a cláusula KEY na definição do elemento de nó ou aresta. Para saber como usar a KEY cláusula ao criar um elemento de gráfico, consulte os exemplos de código neste documento e em Criar um Spanner Graph com uma visualização SQL.

Garantir a exclusividade da chave de nó e aresta

Cada nó e aresta em um gráfico de propriedades precisa ter uma chave exclusiva. Ao definir elementos de gráfico usando visualizações, é possível escolher como a exclusividade da chave do elemento é verificada:

Validação de chave estrita (padrão)

Por padrão, o Spanner verifica se as visualizações que definem tabelas de nós ou arestas seguem um dos padrões a seguir para garantir que cada nó ou aresta seja exclusivo:

  • Padrão 1: a visualização usa a chave primária de uma única tabela.

  • Padrão 2: a visualização usa uma GROUP BY ou uma SELECT DISTINCT cláusula.

É possível usar outros operadores SQL, como WHERE, HAVING, ORDER BY,LIMIT e TABLESAMPLE, em combinação com esses padrões. Esses operadores filtram ou ordenam os resultados, mas não mudam a garantia de exclusividade subjacente que os padrões fornecem.

Padrão 1: usar a chave primária de uma única tabela

Nesse padrão, a visualização seleciona uma única tabela, e a cláusula KEY na definição do gráfico corresponde às colunas de chave primária da tabela base. Por isso, cada linha de nó ou aresta produzida pela visualização é exclusiva.

Por exemplo, o seguinte seleciona um subconjunto de linhas da tabela Account. O gráfico KEY(account_id) corresponde à chave primária da tabela Account, o que garante que cada linha produzida pela visualização seja exclusiva.

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

Padrão 2: usar a cláusula GROUP BY ou SELECT DISTINCT

Nesse padrão, a consulta da visualização usa uma cláusula GROUP BY ou SELECT DISTINCT. As colunas na cláusula KEY precisam corresponder às colunas que essas cláusulas usam para definir a exclusividade:

  • Para GROUP BY: as colunas da cláusula KEY precisam corresponder a todas as colunas na cláusula GROUP BY.

  • Para SELECT DISTINCT: as colunas da cláusula KEY precisam corresponder às colunas na lista SELECT DISTINCT.

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

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

Validação de chave desativada (qualquer consulta SQL)

Se a visualização usar uma consulta que não segue Padrão 1 ou Padrão 2, como uma consulta que une tabelas sem uma GROUP BY ou SELECT DISTINCT cláusula, é possível desativar a validação da chave do elemento definindo a opção de gráfico validate_element_key_uniqueness = false.

Por padrão, validate_element_key_uniqueness é true. Quando definido como false, o Spanner não valida a definição de consulta da visualização no momento da criação do esquema. É possível usar qualquer consulta SQL na visualização, mas é necessário garantir que as colunas especificadas na cláusula KEY contenham valores exclusivos para cada linha de nó ou aresta.

O exemplo a seguir define uma visualização chamada CustomerOrderTrusted que une as Customer e SaleOrder tabelas sem uma GROUP BY cláusula. Como cada pedido de venda é exclusivo, a união de SaleOrder com Customer preserva a exclusividade de order_id nos resultados da visualização. No entanto, como a consulta usa um JOIN e não segue o Padrão 1 ou Padrado 2, o Spanner não pode verificar a exclusividade sintaticamente.

Ao especificar KEY(order_id) e definir validate_element_key_uniqueness = false na cláusula OPTIONS, é possível definir o gráfico de propriedades sem modificar a consulta de visualização:

-- View uses a JOIN without GROUP BY or DISTINCT.
CREATE VIEW CustomerOrderTrusted
  SQL SECURITY INVOKER AS
    SELECT
      s.order_id,
      c.customer_id,
      c.name AS customer_name
    FROM Customer c JOIN SaleOrder s ON c.customer_id = s.customer_id;

-- Property graph disables element key uniqueness validation.
CREATE PROPERTY GRAPH OrderGraphTrusted
  NODE TABLES (
    CustomerOrderTrusted
      KEY(order_id)
      LABEL CustomerOrder PROPERTIES(
        order_id,
        customer_id,
        customer_name)
  ) OPTIONS (validate_element_key_uniqueness = false);

Considerações ao usar visualizações

Ao usar visualizações para definir elementos de gráfico, o seguinte pode ajudar você a projetar e implementar um gráfico eficaz:

Desempenho da consulta do gráfico de propriedades

Ao definir elementos de gráfico em visualizações que executam transformações de dados (por exemplo, operações GROUP BY, UNNEST ou JOIN), avalie cuidadosamente o desempenho da consulta para seu caso de uso. Lembre-se de que o Spanner executa a definição de consulta de uma visualização sempre que uma consulta realiza a correspondência de padrões de elementos.

Otimização do esquema de gráfico

Ao usar visualizações para definir elementos de gráfico, algumas otimizações de esquema de gráfico podem ser menos eficazes do que quando você usa tabelas para definir elementos de gráfico.

Visualizações que projetam a chave primária de uma única tabela

Se uma visualização for uma projeção de uma única tabela base, todas as otimizações nessa tabela subjacente permanecerão eficazes para consultas de gráfico. Por exemplo, a aplicação das técnicas a seguir às tabelas base oferece benefícios de desempenho semelhantes para elementos de gráfico definidos nessas visualizações:

Visualizações definidas com a cláusula GROUP BY ou DISTINCT

As visualizações que executam agregações, como GROUP BY, SELECT DISTINCT ou outras transformações complexas, perdem a relação direta com a estrutura da tabela subjacente. Por isso, as otimizações de esquema nas tabelas base podem não oferecer os mesmos benefícios de desempenho para consultas de gráfico que operam nas visualizações. Avalie cuidadosamente o desempenho da consulta para seu caso de uso quando as visualizações executarem agregações complexas.

Modificação de dados com gráficos baseados em visualização

As visualizações não são materializadas, o que significa que elas não armazenam os resultados da consulta que define a visualização como uma tabela no armazenamento de dados e são somente leitura. Por isso, para inserir, atualizar ou descartar nós ou arestas em um gráfico criado com visualizações, modifique os dados nas tabelas usadas para criar as visualizações.

Tratamento de erros de grafo para aplicar a integridade de dados

Ao usar visualizações para definir elementos de grafo, aplique a integridade de dados (por exemplo, aplique tipos de dados) nas tabelas base subjacentes. Caso contrário, os dados nas tabelas base poderão ser inválidos e causar falhas nas consultas no gráfico baseado em visualização durante a execução.

Por exemplo, ao fazer a transição de um grafo sem esquema para um grafo formalizado, use restrições CHECK para validar os dados nas tabelas base (GraphNode e GraphEdge). O código a seguir aplica essas restrições nas propriedades JSON para garantir a integridade de dados na origem e evitar erros de consulta de tempo de execução.

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

A seguir