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

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

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

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

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

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

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

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

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

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

שימוש בתצוגות שמבטיחות שהצמתים והקצוות יהיו ייחודיים

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

  • תבנית 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)
  );

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

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

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

כשמגדירים רכיבי תרשים בתצוגות שמבצעות טרנספורמציות של נתונים (לדוגמה, פעולות 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));

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