Ringkasan grafik yang dibuat dari tampilan SQL

Gunakan dokumen ini untuk mempelajari manfaat penggunaan tampilan SQL dalam membuat grafik. Dokumen ini mencakup manfaat membuat grafik dengan tampilan, persyaratan, dan pertimbangan untuk membantu Anda memutuskan apakah Anda 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 dijalankan setiap kali kueri yang merujuk ke tampilan dijalankan. Tampilan Spanner bukan tampilan terwujud karena tidak menyimpan hasil kueri yang menentukan tampilan sebagai tabel aktual dalam penyimpanan data. Untuk mengetahui informasi selengkapnya, lihat Ringkasan tampilan. Anda dapat membuat elemen grafik dari tampilan SQL, tetapi Anda tidak dapat membuat tampilan yang mengkueri grafik.

Tampilan 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 ini saat menggunakan tampilan untuk membuat elemen grafik:

Gunakan klausa KEY saat Anda menentukan elemen grafik

Anda harus menentukan secara eksplisit kolom yang mengidentifikasi elemen grafik secara unik saat Anda menggunakan tampilan untuk membuat elemen node atau tepi. Untuk melakukannya, gunakan klausul 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 tampilan yang menentukan tabel node atau edge mengikuti salah satu pola berikut untuk memastikan bahwa setiap node atau edge bersifat unik:

  • Pola 1: Tampilan menggunakan kunci primer satu tabel.

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

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

Pola 1: Menggunakan kunci utama satu tabel

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, 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 menyetel opsi grafik validate_element_key_uniqueness = false.

Secara default, validate_element_key_uniqueness adalah true. Jika disetel ke false, Spanner tidak 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);

Pertimbangan saat menggunakan tampilan

Saat Anda menggunakan tampilan untuk menentukan elemen grafik, hal berikut dapat membantu Anda mendesain dan menerapkan 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 dengan cermat performa kueri untuk kasus penggunaan Anda. Ingatlah 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 tetap efektif untuk kueri grafik. Misalnya, menerapkan teknik berikut ke tabel dasar 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, 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 Anda melakukan agregasi yang kompleks.

Modifikasi data dengan grafik berbasis tampilan

Tampilan tidak terwujud, yang berarti 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 tepi dalam grafik yang dibuat dari tampilan, Anda harus mengubah data dalam tabel yang digunakan untuk membuat tampilan.

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 Anda gagal saat runtime.

Misalnya, saat Anda beralih dari tanpa skema ke grafik yang diformalisasi, gunakan batasan CHECK untuk memvalidasi data dalam tabel dasar Anda (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