Panoramica dei grafici creati dalle viste SQL

Utilizza questo documento per scoprire i vantaggi dell'utilizzo delle viste SQL per creare un grafico. Questo documento include i vantaggi della creazione di grafici con viste, i requisiti e le considerazioni per aiutarti a decidere se utilizzare tabelle o viste per creare un grafico.

Per informazioni dettagliate su come creare un grafico dalle visualizzazioni, consulta Crea un grafico delle proprietà dalle visualizzazioni SQL.

Vantaggi della creazione di grafici con visualizzazioni anziché tabelle

Una vista SQL è una tabella virtuale definita da una query SQL. In Spanner, la query che definisce una vista viene eseguita ogni volta che viene eseguita una query che fa riferimento alla vista. Le viste Spanner non sono viste materializzate perché non memorizzano i risultati della query che definisce la vista come una tabella effettiva nel datastore. Per saperne di più, consulta la panoramica delle visualizzazioni. Puoi creare elementi del grafico da viste SQL, ma non puoi creare una vista che esegue query su un grafico.

Le viste offrono diversi vantaggi come livello di astrazione tra le tabelle e uno schema del grafo che non sono disponibili quando utilizzi le tabelle per creare un grafo.

Requisiti per l'utilizzo delle visualizzazioni per creare grafici

Quando utilizzi le visualizzazioni per creare elementi del grafico, devi rispettare i seguenti requisiti:

Utilizza la clausola KEY quando specifichi un elemento del grafico

Devi definire esplicitamente le colonne che identificano in modo univoco l'elemento del grafico quando utilizzi le visualizzazioni per creare un nodo o un arco. Per farlo, utilizza la clausola KEY nella definizione dell'elemento nodo o arco. Per scoprire come utilizzare la clausola KEY durante la creazione di un elemento del grafo, consulta gli esempi di codice in questo documento e in Crea uno Spanner Graph da una vista SQL.

Assicurati che le chiavi dei nodi e degli archi siano univoche

Ogni nodo e arco in un grafico delle proprietà deve avere una chiave univoca. Quando definisci gli elementi del grafico utilizzando le visualizzazioni, puoi scegliere come verificare l'unicità della chiave degli elementi:

Convalida rigorosa delle chiavi (impostazione predefinita)

Per impostazione predefinita, Spanner verifica che le viste che definiscono le tabelle di nodi o archi seguano uno dei seguenti pattern per garantire che ogni nodo o arco sia univoco:

  • Pattern 1: la vista utilizza la chiave primaria di una singola tabella.

  • Pattern 2: la vista utilizza una clausola GROUP BY o SELECT DISTINCT.

Puoi utilizzare altri operatori SQL come WHERE, HAVING, ORDER BY,LIMIT e TABLESAMPLE in combinazione con questi pattern. Questi operatori filtrano o ordinano i risultati, ma non modificano la garanzia di unicità sottostante fornita dai pattern.

Pattern 1: utilizza la chiave primaria di una singola tabella

In questo pattern, la vista seleziona da una singola tabella e la clausola KEY nella definizione del grafo corrisponde alle colonne della chiave primaria della tabella di base. Per questo motivo, ogni riga di nodo o arco prodotta dalla vista è univoca.

Ad esempio, il seguente comando seleziona un sottoinsieme di righe dalla tabella Account. Il grafico KEY(account_id) corrisponde alla chiave primaria della tabella Account, il che garantisce che ogni riga prodotta dalla vista sia univoca.

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

Pattern 2: utilizza la clausola GROUP BY o SELECT DISTINCT

In questo pattern, la query della vista utilizza una clausola GROUP BY o SELECT DISTINCT. Le colonne nella clausola KEY devono corrispondere alle colonne utilizzate da queste clausole per definire l'univocità:

  • Per GROUP BY: le colonne della clausola KEY devono corrispondere a tutte le colonne della clausola GROUP BY.

  • Per SELECT DISTINCT: le colonne della clausola KEY devono corrispondere alle colonne nell'elenco SELECT DISTINCT.

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

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

Convalida della chiave disattivata (qualsiasi query SQL)

Se la vista utilizza una query che non segue il Pattern 1 o il Pattern 2, ad esempio una query che unisce tabelle senza una clausola GROUP BY o SELECT DISTINCT, puoi disattivare la convalida della chiave dell'elemento impostando l'opzione del grafico validate_element_key_uniqueness = false.

Per impostazione predefinita, validate_element_key_uniqueness è true. Se impostato su false, Spanner non convalida la definizione della query della vista al momento della creazione dello schema. Puoi utilizzare qualsiasi query SQL nella vista, ma devi assicurarti che le colonne specificate nella clausola KEY contengano valori univoci per ogni riga di nodo o arco.

L'esempio seguente definisce una vista denominata CustomerOrderTrusted che unisce le tabelle Customer e SaleOrder senza una clausola GROUP BY. Poiché ogni ordine di vendita è univoco, l'unione di SaleOrder con Customer preserva l'univocità di order_id nei risultati della vista. Tuttavia, poiché la query utilizza un JOIN e non segue il Pattern 1 o il Pattern 2, Spanner non può verificare l'unicità in modo sintattico.

Specificando KEY(order_id) e impostando validate_element_key_uniqueness = false nella clausola OPTIONS, puoi definire il grafico delle proprietà senza modificare la query della vista:

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

Abilita le colonne volatili quando le viste utilizzano funzioni remote

Puoi definire un grafo delle proprietà su una vista che chiama una funzione remota (LANGUAGE REMOTE) impostando allow_view_with_volatile_column = true nella clausola OPTIONS dell'istruzione CREATE PROPERTY GRAPH.

Per impostazione predefinita, Spanner non consente di definire un grafico delle proprietà su viste con colonne volatili (allow_view_with_volatile_column = false). Una colonna della vista è volatile se la sua espressione chiama una funzione volatile. Una funzione è volatile se il suo valore restituito può cambiare anche all'interno di una singola esecuzione di istruzione con gli stessi argomenti, ad esempio una funzione remota (NOT DETERMINISTIC). Qualsiasi volatilità nel corpo della definizione di una vista, ad esempio in una condizione JOIN o in una clausola WHERE, rende volatili anche tutte le colonne proiettate nella vista. Per un esempio di codice, consulta Calcola le proprietà con le funzioni remote.

Considerazioni sull'utilizzo delle viste

Quando utilizzi le visualizzazioni per definire gli elementi del grafo, i seguenti suggerimenti possono aiutarti a progettare e implementare un grafo efficace:

Prestazioni delle query sui grafici delle proprietà

Quando definisci gli elementi del grafo su viste che eseguono trasformazioni dei dati (ad esempio operazioni GROUP BY, UNNEST o JOIN), valuta attentamente le prestazioni delle query per il tuo caso d'uso. Ricorda che Spanner esegue la definizione della query di una vista ogni volta che una query esegue la corrispondenza di pattern degli elementi.

Ottimizzazione dello schema del grafo

Quando utilizzi le visualizzazioni per definire gli elementi del grafico, alcune ottimizzazioni dello schema del grafico potrebbero essere meno efficaci rispetto a quando utilizzi le tabelle per definire gli elementi del grafico.

Viste che proiettano la chiave primaria di una singola tabella

Se una vista è una proiezione di una singola tabella di base, le ottimizzazioni della tabella sottostante rimangono valide per le query sul grafo. Ad esempio, l'applicazione delle seguenti tecniche alle tabelle di base offre vantaggi in termini di prestazioni simili per gli elementi del grafico definiti in queste viste:

Viste definite con la clausola GROUP BY o DISTINCT

Le viste che eseguono aggregazioni, come GROUP BY, SELECT DISTINCT o altre trasformazioni complesse, perdono la relazione diretta con la struttura della tabella sottostante. Per questo motivo, le ottimizzazioni dello schema sulle tabelle di base potrebbero non fornire gli stessi vantaggi in termini di prestazioni per le query sui grafici che operano sulle viste. Valuta attentamente le prestazioni delle query per il tuo caso d'uso quando le viste eseguono aggregazioni complesse.

Modifica dei dati con grafici basati su visualizzazioni

Le viste non sono materializzate, il che significa che non memorizzano i risultati della query che definisce la vista come tabella nel datastore e sono di sola lettura. Per questo motivo, per inserire, aggiornare o eliminare nodi o archi in un grafico creato da viste, devi modificare i dati nelle tabelle utilizzate per creare le viste.

Gestione degli errori dei grafici per garantire l'integrità dei dati

Quando utilizzi le visualizzazioni per definire gli elementi del grafico, applica l'integrità dei dati (ad esempio, applica i tipi di dati) alle tabelle di base sottostanti. In caso contrario, i dati nelle tabelle di base potrebbero non essere validi e causare errori delle query sul grafico basato sulla vista in fase di runtime.

Ad esempio, quando passi da un grafico senza schema a un grafico formalizzato, utilizza i vincoli CHECK per convalidare i dati nelle tabelle di base (GraphNode e GraphEdge). Il codice seguente applica questi vincoli all'interno delle proprietà JSON per garantire l'integrità dei dati nell'origine ed evitare errori di query di runtime.

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

Passaggi successivi