סקירה כללית של תרשימים שנוצרו מתצוגות SQL

במאמר הזה מוסבר איך אפשר להשתמש בתצוגות SQL כדי ליצור תרשים. במסמך הזה מפורטים היתרונות של יצירת גרפים באמצעות תצוגות, הדרישות והשיקולים שיעזרו לכם להחליט אם כדאי להשתמש בטבלאות או בתצוגות כדי ליצור גרף.

פרטים על יצירת תרשים מתצוגות זמינים במאמר יצירת תרשים מאפיינים מתצוגות SQL.

היתרונות של יצירת גרפים באמצעות תצוגות במקום טבלאות

תצוגה של SQL היא טבלה וירטואלית שמוגדרת על ידי שאילתת SQL. ב-Spanner, השאילתה שמגדירה תצוגה מופעלת בכל פעם שמופעלת שאילתה שמפנה לתצוגה. תצוגות ב-Spanner הן לא תצוגות חומריות כי הן לא מאחסנות את התוצאות של השאילתה שמגדירה את התצוגה כטבלה בפועל באחסון הנתונים. מידע נוסף זמין במאמר סקירה כללית על תצוגות. אפשר ליצור רכיבי גרף מתצוגות SQL, אבל אי אפשר ליצור תצוגה שמבצעת שאילתה בגרף.

לתצוגות יש כמה יתרונות כשמשתמשים בהן כשכבת הפשטה בין טבלאות לבין סכימת גרף, שלא קיימים כשמשתמשים בטבלאות כדי ליצור גרף.

דרישות לשימוש בתצוגות ליצירת תרשימים

כשמשתמשים בתצוגות ליצירת רכיבי תרשים, צריך לפעול לפי הדרישות הבאות:

שימוש בפסוקית KEY כשמציינים רכיב בתרשים

כשמשתמשים בתצוגות כדי ליצור צומת או רכיב קצה, צריך להגדיר באופן מפורש את העמודות שמזהות באופן ייחודי את רכיב הגרף. כדי לעשות את זה, משתמשים בסעיף KEY בהגדרת רכיב הצומת או הקצה. כדי ללמוד איך להשתמש בסעיף KEY כשיוצרים רכיב גרף, אפשר לעיין בדוגמאות הקוד במסמך הזה ובמאמר יצירת גרף Spanner מתצוגת SQL.

הקפדה על ייחודיות של מפתחות צמתים וקשתות

לכל צומת וקצה בגרף נכס צריך להיות מפתח ייחודי. כשמגדירים רכיבי גרף באמצעות תצוגות, אפשר לבחור איך לאמת את הייחודיות של מפתח הרכיב:

אימות קפדני של מפתחות (ברירת מחדל)

כברירת מחדל, Spanner מוודא שתצוגות שמגדירות טבלאות של צמתים או קשתות פועלות לפי אחד מהדפוסים הבאים, כדי להבטיח שכל צומת או קשת יהיו ייחודיים:

  • תבנית 1: התצוגה משתמשת במפתח ראשי של טבלה אחת.

  • דפוס 2: התצוגה משתמשת בתנאי GROUP BY או בתנאי SELECT DISTINCT.

אפשר להשתמש באופרטורים אחרים של SQL כמו WHERE,‏ HAVING,‏ ORDER BY,‏ LIMIT ו-TABLESAMPLE בשילוב עם התבניות האלה. האופרטורים האלה מסננים או מסדרים את התוצאות, אבל הם לא משנים את ההבטחה הבסיסית לגבי הייחודיות שהדפוסים מספקים.

תבנית 1: שימוש במפתח ראשי של טבלה אחת

בדפוס הזה, התצוגה בוחרת מתוך טבלה אחת, והסעיף KEY בהגדרת התרשים תואם לעמודות של המפתח הראשי בטבלת הבסיס. לכן, כל שורה של צומת או קצה שנוצרת על ידי התצוגה היא ייחודית.

לדוגמה, הפקודה הבאה בוחרת קבוצת משנה של שורות מהטבלה Account. הגרף KEY(account_id) תואם למפתח הראשי של הטבלה Account, וכך כל שורה שנוצרת על ידי התצוגה היא ייחודית.

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

תבנית 2: שימוש בסעיף GROUP BY או SELECT DISTINCT

בדפוס הזה, השאילתה של התצוגה משתמשת בתנאי GROUP BY או בתנאי SELECT DISTINCT. העמודות בתנאי KEY צריכות להיות זהות לעמודות שמוגדרות בתנאים האלה כדי להגדיר ייחודיות:

  • במקרה של GROUP BY: העמודות של פסוקית KEY חייבות להיות זהות לכל העמודות בפסוקית GROUP BY.

  • ‫SELECT DISTINCT: העמודות של סעיף KEY צריכות להיות זהות לעמודות ברשימה SELECT DISTINCT.

דוגמה עם 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)
  );

דוגמה עם 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)
  );

השבתת אימות המפתח (כל שאילתת SQL)

אם התצוגה שלכם משתמשת בשאילתה שלא תואמת לתבנית 1 או לתבנית 2 – למשל, שאילתה שמצטרפת לטבלאות בלי פסקה GROUP BY או SELECT DISTINCT – אתם יכולים להשבית את האימות של מפתח הרכיב על ידי הגדרת אפשרות הגרף validate_element_key_uniqueness = false.

כברירת מחדל, הערך של validate_element_key_uniqueness הוא true. אם ההגדרה היא false,‏ Spanner לא מאמת את הגדרת השאילתה של התצוגה בזמן יצירת הסכימה. אפשר להשתמש בכל שאילתת SQL בתצוגה, אבל צריך לוודא שהעמודות שצוינו בסעיף KEY מכילות ערכים ייחודיים לכל שורה של צומת או קצה.

בדוגמה הבאה מוגדרת תצוגה בשם CustomerOrderTrusted שמצטרפת לטבלאות Customer ו-SaleOrder בלי פסקה של GROUP BY. מכיוון שכל הזמנת מכירה היא ייחודית, הצטרפות של SaleOrder אל Customer שומרת על הייחודיות של order_id בתוצאות התצוגה. עם זאת, מכיוון שהשאילתה משתמשת ב-JOIN ולא פועלת לפי תבנית 1 או תבנית 2, ‏ Spanner לא יכול לאמת את הייחודיות באופן תחבירי.

אם מציינים KEY(order_id) ומגדירים את validate_element_key_uniqueness = false בסעיף OPTIONS, אפשר להגדיר את גרף המאפיינים בלי לשנות את שאילתת התצוגה:

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

שיקולים לשימוש בתצוגות

כשמשתמשים בתצוגות כדי להגדיר רכיבי תרשים, המידע הבא יכול לעזור בתכנון ובהטמעה של תרשים יעיל:

ביצועי שאילתות של תרשימי מאפיינים

כשמגדירים רכיבי תרשים בתצוגות שמבצעות טרנספורמציות של נתונים (לדוגמה, פעולות GROUP BY,‏ UNNEST או JOIN), חשוב להעריך בקפידה את ביצועי השאילתה לתרחיש השימוש שלכם. חשוב לזכור שמערכת Spanner מריצה את הגדרת השאילתה של תצוגה בכל פעם ששאילתה מבצעת התאמה של דפוס אלמנט.

אופטימיזציה של סכימת גרף

כשמשתמשים בתצוגות כדי להגדיר רכיבי גרף, יכול להיות שחלק מהאופטימיזציות של סכימת הגרף יהיו פחות יעילות מאשר כשמשתמשים בטבלאות כדי להגדיר רכיבי גרף.

תצוגות שמציגות מפתח ראשי של טבלה אחת

אם תצוגה היא היטל ממסד נתונים טבלאי יחיד, כל האופטימיזציות במסד הנתונים הטבלאי הבסיסי הזה נשארות בתוקף בשאילתות גרף. לדוגמה, שימוש בטכניקות הבאות בטבלאות בסיס מספק יתרונות דומים בביצועים לרכיבי תרשים שמוגדרים בתצוגות כאלה:

תצוגות שהוגדרו באמצעות פסקה של GROUP BY או DISTINCT

בתצוגות שמבצעות צבירות, כמו GROUP BY, SELECT DISTINCT או טרנספורמציות מורכבות אחרות, הקשר הישיר למבנה הטבלה הבסיסי אובד. לכן, אופטימיזציות של סכימות בטבלאות הבסיס לא בהכרח יספקו את אותם יתרונות ביצועים לשאילתות גרף שפועלות בתצוגות. אם התצוגות מבצעות צבירות מורכבות, חשוב להעריך בקפידה את ביצועי השאילתות בהתאם לתרחיש השימוש.

שינוי נתונים באמצעות תרשימים שמבוססים על תצוגה

תצוגות לא ממומשות, כלומר הן לא שומרות את תוצאות השאילתה שמגדירה את התצוגה כטבלה באחסון הנתונים, והן לקריאה בלבד. לכן, כדי להוסיף, לעדכן או להסיר צמתים או קשתות בתרשים שנוצר מתצוגות, צריך לשנות את הנתונים בטבלאות ששימשו ליצירת התצוגות.

טיפול בשגיאות בגרף כדי לאכוף את תקינות הנתונים

כשמשתמשים בתצוגות כדי להגדיר רכיבים של תרשים, צריך לאכוף את תקינות הנתונים (לדוגמה, לאכוף סוגי נתונים) בטבלאות הבסיסיות. אחרת, הנתונים בטבלאות הבסיס עשויים להיות לא תקפים ולגרום לכך ששאילתות בתרשים מבוסס התצוגה ייכשלו בזמן הריצה.

לדוגמה, כשעוברים מגרף ללא סכימה לגרף רשמי, כדאי להשתמש באילוצי CHECK כדי לאמת את הנתונים בטבלאות הבסיס (GraphNode ו-GraphEdge). הקוד הבא מחיל את האילוצים האלה במאפייני ה-JSON כדי לוודא שהנתונים תקינים במקור ולמנוע שגיאות בשאילתות בזמן הריצה.

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

המאמרים הבאים