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 os benefícios de criar 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 saber como criar um gráfico com base em visualizações, consulte Criar um gráfico de propriedades com base em 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 visualizações materializadas porque não armazenam os resultados da consulta que define a visualização como uma tabela real no repositório de dados. Para mais informações, consulte Visão geral das visualizações. É possível criar elementos de gráfico com base em 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

Siga estes requisitos ao usar visualizações para criar elementos de gráfico:

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

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

Garantir a exclusividade das chaves de nó e de borda

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 de bordas seguem um dos seguintes padrões para garantir que cada nó ou borda 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 cláusula GROUP BY ou SELECT DISTINCT.

É 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 alteram 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 de 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 borda produzida pela visualização é exclusiva.

Por exemplo, o código a seguir 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: use 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 o Padrão 1 ou o Padrão 2, como uma consulta que une tabelas sem uma cláusula GROUP BY ou SELECT DISTINCT, é possível desativar a validação de chave de 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 é preciso 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 mescla as tabelas Customer e SaleOrder sem uma cláusula GROUP BY. Como cada pedido de venda é único, a mesclagem 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 o Padrão 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);

Ativar colunas voláteis quando as visualizações usam funções remotas

É possível definir um gráfico de propriedades em uma visualização que chama uma função remota (LANGUAGE REMOTE) definindo allow_view_with_volatile_column = true na cláusula OPTIONS da instrução CREATE PROPERTY GRAPH.

Por padrão, o Spanner não permite definir um gráfico de propriedades em visualizações com colunas voláteis (allow_view_with_volatile_column = false). Uma coluna de visualização é volátil se a expressão dela chama uma função volátil. Uma função será volátil se o valor de retorno dela puder mudar mesmo em uma única execução de instrução com os mesmos argumentos, como uma função remota (NOT DETERMINISTIC). Qualquer volatilidade no corpo de definição de uma visualização, como em uma condição JOIN ou cláusula WHERE, também torna voláteis todas as colunas projetadas na visualização. Para ver um exemplo de código, consulte Calcular propriedades com funções remotas.

Considerações ao usar visualizações

Ao usar visualizações para definir elementos de gráfico, as seguintes informações podem ajudar você a projetar e implementar um gráfico eficaz:

Desempenho de consultas de gráficos de propriedades

Ao definir elementos de gráfico em visualizações que realizam transformações de dados (por exemplo, operações GROUP BY, UNNEST ou JOIN), avalie cuidadosamente a performance 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, aplicar as 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 realizam 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 realizarem 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 repositório de dados, e são somente leitura. Por isso, para inserir, atualizar ou remover nós ou arestas em um gráfico criado com base em visualizações, modifique os dados nas tabelas usadas para criar as visualizações.

Tratamento de erros de grafo para garantir a integridade de dados

Ao usar visualizações para definir elementos de gráfico, aplique a integridade de dados (por exemplo, tipos de dados) nas tabelas base subjacentes. Caso contrário, os dados nas tabelas base podem ser inválidos e fazer com que as consultas no gráfico baseado em visualização falhem no ambiente de execução.

Por exemplo, ao fazer a transição de um grafo sem esquema para um formalizado, use restrições CHECK para validar 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 no ambiente 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