Ringkasan grafik yang dibuat dari tampilan SQL

Gunakan dokumen ini untuk mempelajari manfaat menggunakan tampilan SQL untuk membuat grafik. Dokumen ini mencakup manfaat membuat grafik dengan tampilan, persyaratan, dan pertimbangan untuk membantu Anda memutuskan apakah harus menggunakan tabel atau tampilan untuk membuat grafik.

Untuk mengetahui detail tentang cara membuat grafik dari tampilan, lihat Membuat grafik properti dari tampilan SQL.

Manfaat membuat grafik dengan tampilan, bukan tabel

Tampilan SQL adalah tabel virtual yang ditentukan oleh kueri SQL. Di Spanner, kueri yang menentukan tampilan akan dijalankan setiap kali kueri yang merujuk ke tampilan tersebut dijalankan. Tampilan Spanner bukanlah tampilan terwujud karena tidak menyimpan hasil kueri yang menentukan tampilan sebagai tabel aktual dalam penyimpanan data. Untuk informasi selengkapnya, lihat Ringkasan tampilan. Anda dapat membuat elemen grafik dari tampilan SQL, tetapi Anda tidak dapat membuat tampilan yang mengkueri grafik.

Tabel virtual memberikan beberapa keuntungan sebagai lapisan abstraksi antara tabel dan skema grafik yang tidak tersedia saat Anda menggunakan tabel untuk membuat grafik.

Persyaratan untuk menggunakan tampilan guna membuat grafik

Anda harus mengikuti persyaratan berikut saat menggunakan tampilan untuk membuat elemen grafik:

Menggunakan klausa KEY saat Anda menentukan elemen grafik

Anda harus menentukan kolom yang secara unik mengidentifikasi elemen grafik secara eksplisit saat menggunakan tampilan untuk membuat node atau elemen edge. Untuk melakukannya, gunakan klausa KEY dalam definisi elemen node atau edge. Untuk mempelajari cara menggunakan klausa KEY saat membuat elemen grafik, lihat contoh kode dalam dokumen ini dan di Membuat Spanner Graph dari tampilan SQL.

Memastikan keunikan kunci node dan edge

Setiap node dan edge dalam grafik properti harus memiliki kunci unik. Saat menentukan elemen grafik menggunakan tampilan, Anda dapat memilih cara verifikasi keunikan kunci elemen:

Validasi kunci ketat (default)

Secara default, Spanner memverifikasi bahwa tabel node atau edge yang menentukan tampilan mengikuti salah satu pola berikut untuk memastikan bahwa setiap node atau edge bersifat unik:

  • Pola 1: Tampilan menggunakan kunci utama tabel tunggal.

  • Pola 2: Tampilan menggunakan klausa GROUP BY atau SELECT DISTINCT.

Anda dapat menggunakan operator SQL lainnya seperti WHERE, HAVING, ORDER BY,LIMIT, dan TABLESAMPLE yang dikombinasikan dengan pola ini. Operator ini memfilter atau mengurutkan hasil, tetapi tidak mengubah jaminan keunikan yang mendasari yang disediakan oleh pola.

Pola 1: Menggunakan kunci utama tabel tunggal

Dalam pola ini, tampilan memilih dari satu tabel, dan klausa KEY dalam definisi grafik cocok dengan kolom kunci utama tabel dasar. Oleh karena itu, setiap baris node atau edge yang dihasilkan oleh tampilan bersifat unik.

Misalnya, kode berikut memilih subset baris dari tabel Account. Grafik KEY(account_id) cocok dengan kunci utama tabel Account, yang memastikan bahwa setiap baris yang dihasilkan oleh tampilan bersifat unik.

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

Pola 2: Menggunakan klausa GROUP BY atau SELECT DISTINCT

Dalam pola ini, kueri tampilan menggunakan klausa GROUP BY atau SELECT DISTINCT. Kolom dalam klausa KEY harus cocok dengan kolom yang digunakan klausa ini untuk menentukan keunikan:

  • Untuk GROUP BY: Kolom klausa KEY harus cocok dengan semua kolom dalam klausa GROUP BY.

  • Untuk SELECT DISTINCT: Kolom klausa KEY harus cocok dengan kolom dalam daftar SELECT DISTINCT.

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

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

Validasi kunci dinonaktifkan (kueri SQL apa pun)

Jika tampilan Anda menggunakan kueri yang tidak mengikuti Pola 1 atau Pola 2—seperti kueri yang menggabungkan tabel tanpa klausa GROUP BY atau SELECT DISTINCT—Anda dapat menonaktifkan validasi kunci elemen dengan menetapkan opsi grafik validate_element_key_uniqueness = false.

Secara default, validate_element_key_uniqueness bernilai true. Jika ditetapkan ke false, Spanner tidak akan memvalidasi definisi kueri tampilan pada waktu pembuatan skema. Anda dapat menggunakan kueri SQL apa pun dalam tampilan, tetapi Anda harus memastikan bahwa kolom yang ditentukan dalam klausa KEY berisi nilai unik untuk setiap baris node atau edge.

Contoh berikut menentukan tampilan bernama CustomerOrderTrusted yang menggabungkan tabel Customer dan SaleOrder tanpa klausa GROUP BY. Karena setiap pesanan penjualan bersifat unik, menggabungkan SaleOrder dengan Customer akan mempertahankan keunikan order_id dalam hasil tampilan. Namun, karena kueri menggunakan JOIN dan tidak mengikuti Pola 1 atau Pola 2, Spanner tidak dapat memverifikasi keunikan secara sintaksis.

Dengan menentukan KEY(order_id) dan menetapkan validate_element_key_uniqueness = false dalam klausa OPTIONS, Anda dapat menentukan grafik properti tanpa mengubah kueri tampilan:

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

Mengaktifkan kolom volatil saat tampilan menggunakan fungsi jarak jauh

Anda dapat menentukan grafik properti pada tampilan yang memanggil fungsi jarak jauh (LANGUAGE REMOTE) dengan menetapkan allow_view_with_volatile_column = true dalam klausa OPTIONS dari pernyataan CREATE PROPERTY GRAPH.

Secara default, Spanner tidak mengizinkan Anda menentukan grafik properti pada tampilan dengan kolom volatil (allow_view_with_volatile_column = false). Kolom tampilan bersifat volatil jika ekspresinya memanggil fungsi volatil. Fungsi bersifat volatil jika nilai yang ditampilkan dapat berubah bahkan dalam satu eksekusi pernyataan dengan argumen yang sama, seperti fungsi jarak jauh (NOT DETERMINISTIC). Setiap volatilitas dalam isi definisi tampilan, seperti dalam kondisi JOIN atau klausa WHERE, juga membuat semua kolom yang diproyeksikan dalam tampilan menjadi volatil. Untuk contoh kode, lihat Menghitung properti dengan fungsi jarak jauh.

Pertimbangan saat menggunakan tampilan

Saat Anda menggunakan tampilan untuk menentukan elemen grafik, hal berikut dapat membantu Anda mendesain dan mengimplementasikan grafik yang efektif:

Performa kueri grafik properti

Saat Anda menentukan elemen grafik pada tampilan yang melakukan transformasi data (misalnya, operasi GROUP BY, UNNEST, atau JOIN), evaluasi performa kueri dengan cermat untuk kasus penggunaan Anda. Ingat bahwa Spanner menjalankan definisi kueri tampilan setiap kali kueri melakukan pencocokan pola elemen.

Pengoptimalan skema grafik

Saat Anda menggunakan tampilan untuk menentukan elemen grafik, beberapa pengoptimalan skema grafik mungkin kurang efektif dibandingkan saat Anda menggunakan tabel untuk menentukan elemen grafik.

Tampilan yang memproyeksikan kunci utama satu tabel

Jika tampilan adalah proyeksi dari satu tabel dasar, pengoptimalan apa pun pada tabel pokok tersebut akan tetap efektif untuk kueri grafik. Misalnya, menerapkan teknik berikut ke tabel dasar akan memberikan manfaat performa yang serupa untuk elemen grafik yang ditentukan pada tampilan tersebut:

Tampilan yang ditentukan dengan klausa GROUP BY atau DISTINCT

Tampilan yang melakukan agregasi, seperti GROUP BY, SELECT DISTINCT, atau transformasi kompleks lainnya, akan kehilangan hubungan langsung dengan struktur tabel yang mendasarinya. Oleh karena itu, pengoptimalan skema pada tabel dasar mungkin tidak memberikan manfaat performa yang sama untuk kueri grafik yang beroperasi pada tampilan. Evaluasi performa kueri dengan cermat untuk kasus penggunaan Anda saat tampilan melakukan agregasi yang kompleks.

Modifikasi data dengan grafik berbasis tampilan

Tampilan tidak terwujud, yang berarti tampilan tidak menyimpan hasil kueri yang menentukan tampilan sebagai tabel dalam penyimpanan data, dan bersifat hanya baca. Oleh karena itu, untuk menyisipkan, memperbarui, atau menghapus node atau edge dalam grafik yang dibuat dari tabel virtual, Anda harus mengubah data dalam tabel yang digunakan untuk membuat tabel virtual tersebut.

Penanganan error grafik untuk menerapkan integritas data

Saat Anda menggunakan tampilan untuk menentukan elemen grafik, terapkan integritas data (misalnya, terapkan jenis data) pada tabel dasar yang mendasarinya. Jika tidak, data dalam tabel dasar mungkin tidak valid dan menyebabkan kueri pada grafik berbasis tampilan gagal saat runtime.

Misalnya, saat Anda beralih dari tanpa skema ke grafik formal, gunakan batasan CHECK untuk memvalidasi data dalam tabel dasar (GraphNode dan GraphEdge). Kode berikut menerapkan batasan ini dalam properti JSON untuk memastikan integritas data di sumber dan mencegah error kueri 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));

Langkah berikutnya