שיטות מומלצות לעיצוב סכימת Spanner Graph

הערה: התכונה הזו זמינה במהדורות Spanner Enterprise ו-Enterprise Plus. מידע נוסף זמין במאמר סקירה כללית על מהדורות Spanner.

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

מידע על תכנון סכימות של Spanner (לא סכימות של Spanner Graph) זמין במאמר שיטות מומלצות לתכנון סכימות.

בחירת עיצוב סכימה

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

עיצובים עם סכימה לעומת עיצובים ללא סכימה

• עיצוב סכמטי שומר את הגדרת הגרף בסכימת Spanner Graph, שמתאימה לגרפים יציבים עם שינויים לא תכופים בהגדרה. הסכימה אוכפת את הגדרת הגרף, והמאפיינים תומכים בכל סוגי הנתונים של Spanner.

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

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

תכונה	ניהול נתונים מתוכננים	ניהול נתונים ללא סכימה
אחסון הגדרת הגרף	הגדרת הגרף מאוחסנת בסכימת ה-Spanner Graph.	הגדרת הגרף ברורה מהנתונים. עם זאת, Spanner Graph לא בודק את הנתונים כדי להסיק את ההגדרה.
מתבצע עדכון של הגדרת התרשים	נדרש שינוי בסכימת Spanner Graph. מתאים אם ההגדרה מוגדרת היטב ומשתנה לעיתים רחוקות.	אין צורך לשנות את סכימת Spanner Graph.
אכיפה של הגדרת הגרף	סכימה של גרף מאפיינים אוכפת את סוגי הצמתים המותרים לקצה. היא גם אוכפת את המאפיינים המותרים ואת סוגי המאפיינים של צומת או קשת בגרף.	לא נאכף כברירת מחדל. אפשר להשתמש ב-check constraints כדי לאכוף את תקינות הנתונים של התוויות והמאפיינים.
סוגי נתונים של נכסים	תמיכה בכל סוג נתונים של Spanner, לדוגמה: timestamp.	מאפיינים דינמיים חייבים להיות ערך JSON תקין.

בחירת עיצוב סכימה על סמך שאילתות גרף

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

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

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

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

עיצוב ללא סכימה

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

• תבנית הנתיב הכמותית בשאילתה הזו משתמשת בכמה סוגים של קצוות (Transfer או Withdraw) ולא מציינת סוגים של צמתים ביניים לנתיבים ארוכים יותר מצעד אחד.

  GRAPH FinGraph
  MATCH p = (:Account {id:1})-[:Transfer|Withdraw]->{1,3}(:Account)
  RETURN TO_JSON(p) AS p;
  

• תבנית הנתיב הכמותית בשאילתה הזו מוצאת נתיבים של קפיצה אחת עד שלוש קפיצות בין הצמתים Person ו-Account, באמצעות כמה סוגים של קצוות (Owns או Transfers), בלי לציין סוגי צמתים ביניים לנתיבים ארוכים יותר. כך אפשר להעביר נתיבים בין צמתים ביניים מסוגים שונים. לדוגמה, (:Person)-[:Owns]->(:Account)-[:Transfers]->(:Account).

  GRAPH FinGraph
  MATCH p = (:Person {id:1})-[:Owns|Transfers]->{1,3}(:Account)
  RETURN TO_JSON(p) AS p;
  

• דפוס הנתיב הכמותי של השאילתה הזו מוצא נתיבים עם קפיצה אחת עד שלוש בין הצמתים Person ו-Account, בלי לציין תוויות קצה. בדומה לשאילתה הקודמת, היא מאפשרת לנתיבים לעבור בין צמתים ביניים מסוגים שונים.

  GRAPH FinGraph
  MATCH p = (:Person {id:1})-[]->{1,3}(:Account)
  RETURN TO_JSON(p) AS p;
  

• השאילתה הזו מוצאת נתיבים של צעד אחד עד שלושה צעדים בין צמתי Account באמצעות קצוות מסוג Owns בכל כיוון (-[:Owns]-). מכיוון שנתיבים יכולים לעבור קצוות בכל כיוון, ולא מצוינים צמתים ביניים, נתיב של שני צעדים עשוי לעבור דרך צמתים מסוגים שונים. לדוגמה, (:Account)-[:Owns]-(:Person)-[:Owns]-(:Account).

  GRAPH FinGraph
  MATCH p = (:Account {id:1})-[:Owns]-{1,3}(:Account)
  RETURN TO_JSON(p) AS p;
  

שני העיצובים

השאילתה הבאה פועלת באופן דומה עם עיצובים מתוכננים ועם עיצובים ללא תכנון. הנתיב הכמותי שלו, (:Account)-[:Transfer]->{1,3}(:Account), כולל סוג אחד של צומת, Account, וסוג אחד של קצה, Transfer. מכיוון שהנתיב כולל רק סוג אחד של צומת וסוג אחד של קצה, הביצועים דומים בשני העיצובים. למרות שצמתי הביניים לא מסומנים באופן מפורש, התבנית מגבילה אותם להיות צמתי Account. הצומת Person מופיע מחוץ לנתיב הכמותי הזה.

GRAPH FinGraph
MATCH p = (:Person {id:1})-[:Owns]->(:Account)-[:Transfer]->{1,3}(:Account)
RETURN TO_JSON(p) AS p;

אופטימיזציה של ביצועי סכימת Spanner Graph

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

• אופטימיזציה של מעבר הקצה
• שימוש באינדקסים משניים לסינון מאפיינים

אופטימיזציה של מעבר בין קצוות

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

אפשר לעבור על קצה בשני כיוונים:

• מעבר קדימה לאורך הקצה מתבצע לאורך הקצוות היוצאים של צומת המקור.
• מעבר הפוך בין קצוות עוקב אחרי קצוות נכנסים של צומת היעד.

דוגמאות לשאילתות של מעבר קדימה ואחורה בין קצוות

השאילתה הבאה לדוגמה מבצעת מעבר קדימה של קצוות Owns עבור אדם נתון:

GRAPH FinGraph
MATCH (person:Person {id: 1})-[owns:Owns]->(accnt:Account)
RETURN accnt.id;

השאילתה הבאה לדוגמה מבצעת מעבר הפוך של קשתות Owns עבור חשבון נתון:

GRAPH FinGraph
MATCH (accnt:Account {id: 1})<-[owns:Owns]-(person:Person)
RETURN person.name;

אופטימיזציה של מעבר קדימה בקצה

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

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

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

בדוגמאות הבאות מוצגות דרכים להשתמש בשילוב עם אילוץ של מפתח זר מחייב ועם אילוץ של מפתח זר אינפורמטיבי.

מפתח זר נאכף

בדוגמה הזו של טבלת קצה, הפונקציה PersonOwnAccount מבצעת את הפעולות הבאות:

• הנתונים משולבים בטבלת צומתי המקור Person.

• יוצר מפתח זר מאולץ לטבלת צומת היעד Account.

CREATE TABLE Person (
  id               INT64 NOT NULL,
  name             STRING(MAX),
) PRIMARY KEY (id);

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
  close_time       TIMESTAMP,
) PRIMARY KEY (id)

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id)
    REFERENCES Account (id)
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

מפתח זר אינפורמטיבי

בדוגמה הזו של טבלת קצה, הפונקציה PersonOwnAccount מבצעת את הפעולות הבאות:

• הנתונים משולבים בטבלת צומתי המקור Person.

• יוצר מפתח זר אינפורמטיבי לטבלת צומת היעד Account.

CREATE TABLE Person (
  id               INT64 NOT NULL,
  name             STRING(MAX),
) PRIMARY KEY (id);

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
  close_time       TIMESTAMP,
) PRIMARY KEY (id)

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id)
    REFERENCES Account (id) NOT ENFORCED
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

אופטימיזציה של מעבר קצה הפוך

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

כדי לבצע אופטימיזציה של מעבר קצה הפוך, אפשר לבצע את הפעולות הבאות:

• יוצרים אינדקס משני בטבלת הקצה.

• משלבים את האינדקס בטבלת הקלט של צומת היעד כדי למקם את הקצוות יחד עם צמתי היעד.

• מאחסנים את מאפייני הקצה באינדקס.

בדוגמה הזו מוצג אינדקס משני לאופטימיזציה של מעבר קשת הפוך בטבלת הקשתות PersonOwnAccount:

• הפסקה INTERLEAVE IN ממקמת את נתוני האינדקס בטבלה של צומת היעד Account.

• הפסקה STORING מאחסנת את מאפייני הקצה באינדקס.

מידע נוסף על שילוב אינדקסים מופיע במאמר אינדקסים ושילוב.

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE INDEX AccountOwnedByPerson
ON PersonOwnAccount (account_id)
STORING (create_time),
INTERLEAVE IN Account;

שימוש באינדקסים משניים לסינון מאפיינים

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

איך מסננים צמתים לפי מאפיין מהר יותר

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

GRAPH FinGraph
MATCH (acct:Account)
WHERE acct.nick_name = "abcd"
RETURN acct.id;

כדי לזרז את תהליך הסינון, יוצרים אינדקס משני במאפיין המסונן בסכימה:

CREATE TABLE Account (
  id               INT64 NOT NULL,
  create_time      TIMESTAMP,
  is_blocked       BOOL,
  nick_name        STRING(MAX),
) PRIMARY KEY (id);

CREATE INDEX AccountByNickName
ON Account (nick_name);

טיפ: כדאי להשתמש באינדקסים עם סינון NULL למאפיינים דלילים. מידע נוסף מופיע במאמר השבתת הוספה לאינדקס של ערכי NULL.

שיפור המהירות של סינון קצוות לפי מאפיין

אפשר להשתמש באינדקס משני כדי לשפר את הביצועים של סינון קצוות על סמך ערכי מאפיינים.

העברה של קצה קדימה

בלי אינדקס משני, השאילתה הזו צריכה לסרוק את כל הקצוות של אדם כדי למצוא את הקצוות שתואמים למסנן create_time:

GRAPH FinGraph
MATCH (person:Person)-[owns:Owns]->(acct:Account)
WHERE person.id = 1
  AND owns.create_time >= PARSE_TIMESTAMP("%c", "Thu Dec 25 07:30:00 2008")
RETURN acct.id;

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

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE INDEX PersonOwnAccountByCreateTime
ON PersonOwnAccount (id, create_time),
INTERLEAVE IN Person;

מעבר הפוך על קצה הגרף

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

GRAPH FinGraph
MATCH (acct:Account)<-[owns:Owns]-(person:Person)
WHERE acct.id = 1
  AND owns.create_time >= PARSE_TIMESTAMP("%c", "Thu Dec 25 07:30:00 2008")
RETURN person.id;

הקוד הבא משפר את יעילות השאילתה על ידי יצירת אינדקס משני בהפניה לצומת היעד של Edge ‏ (account_id) ובמאפיין Edge ‏(create_time). השאילתה גם מגדירה את האינדקס כצאצא משולב של טבלת צומת היעד, שממקמת את האינדקס באותו מיקום עם צומת היעד.

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE;

CREATE INDEX AccountOwnedByPersonByCreateTime
ON PersonOwnAccount (account_id, create_time),
INTERLEAVE IN Account;

מניעת קצוות תלויים

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

• שימוש באילוצים של הפניות.
• אופציונלי: משתמשים בסעיף ON DELETE CASCADE כשמוחקים צומת עם קצוות שעדיין מחוברים. אם לא משתמשים ב-ON DELETE CASCADE, ניסיונות למחוק צומת בלי למחוק את הקשתות המתאימות ייכשלו.

שימוש באילוצי הפניה

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

1. משלבים את טבלת הקלט של קצה הגרף בטבלת הקלט של צומת המקור כדי לוודא שצומת המקור של קצה הגרף תמיד קיים.

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

הערה: אי אפשר למנוע קצה תלוי באמצעות מפתח זר אינפורמטיבי.

בדוגמה הבאה נעשה שימוש במפתח זר שנאכף, והטבלה של קלט הקצה משולבת בטבלה של קלט צומת המקור באמצעות פסוקית INTERLEAVE IN PARENT. בנוסף, שימוש במפתח זר מאולץ ובשילוב יכול לעזור לשפר את המעבר בין קצוות.

  CREATE TABLE PersonOwnAccount (
    id               INT64 NOT NULL,
    account_id       INT64 NOT NULL,
    create_time      TIMESTAMP,
    CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) ON DELETE CASCADE,
  ) PRIMARY KEY (id, account_id),
    INTERLEAVE IN PARENT Person ON DELETE CASCADE;

מחיקת קצוות באמצעות ON DELETE CASCADE

כשמשתמשים בשילוב או במפתח זר מאולץ כדי למנוע קצוות תלויים, צריך להשתמש בסעיף ON DELETE CASCADE בסכימת Spanner Graph כדי למחוק את הקצוות המשויכים לצומת באותה טרנזקציה שבה הצומת נמחק. מידע נוסף מופיע במאמרים בנושא מחיקה מדורגת של טבלאות משולבות ופעולות של מפתח זר.

מחיקה מדורגת של קצוות שמקשרים בין סוגים שונים של צמתים

בדוגמאות הבאות אפשר לראות איך משתמשים ב-ON DELETE CASCADE בסכימת Spanner Graph כדי למחוק קשתות תלויות כשמוחקים צומת מקור או צומת יעד. בשני המקרים, הסוג של הצומת שנמחק והסוג של הצומת שמחובר אליו באמצעות קצה שונים.

צומת מקור

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

CREATE TABLE PersonOwnAccount (
  id               INT64 NOT NULL,
  account_id       INT64 NOT NULL,
  create_time      TIMESTAMP,
  CONSTRAINT FK_Account FOREIGN KEY (account_id) REFERENCES Account (id) ON DELETE CASCADE,
) PRIMARY KEY (id, account_id),
  INTERLEAVE IN PARENT Person ON DELETE CASCADE

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

צומת היעד

משתמשים באילוץ של מפתח זר כדי למחוק קצוות תלויים כשצומת היעד נמחק. בדוגמה הבאה אפשר לראות איך משתמשים במפתח זר עם ON DELETE CASCADE בטבלת קצוות כדי למחוק קצוות נכנסים כשמוחקים את צומת היעד (Account):

CONSTRAINT FK_Account FOREIGN KEY(account_id)
  REFERENCES Account(id) ON DELETE CASCADE

מחיקה מדורגת של קצוות שמחברים בין צמתים מאותו סוג

אם צומתי המקור והיעד של קשת הם מאותו סוג והקשת משולבת בצומת המקור, אפשר להגדיר ON DELETE CASCADE לצומת המקור או לצומת היעד, אבל לא לשניהם.

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

בדוגמה הבאה, AccountTransferAccount היא טבלת הקלט של ה-Edge. היא מגדירה שני מפתחות זרים, אחד בכל צומת קצה של קשת ההעברה, שניהם עם הפעולה ON DELETE CASCADE.

CREATE TABLE AccountTransferAccount (
  id               INT64 NOT NULL,
  to_id            INT64 NOT NULL,
  amount           FLOAT64,
  create_time      TIMESTAMP NOT NULL,
  order_number     STRING(MAX),
  CONSTRAINT FK_FromAccount FOREIGN KEY (id) REFERENCES Account (id) ON DELETE CASCADE,
  CONSTRAINT FK_ToAccount FOREIGN KEY (to_id) REFERENCES Account (id) ON DELETE CASCADE,
) PRIMARY KEY (id, to_id);

הגדרת אורך חיים (TTL) בצמתים ובקצוות

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

בדוגמה הבאה נעשה שימוש ב-TTL כדי למחוק חשבונות 90 יום אחרי הסגירה שלהם:

  CREATE TABLE Account (
    id               INT64 NOT NULL,
    create_time      TIMESTAMP,
    close_time       TIMESTAMP,
  ) PRIMARY KEY (id),
    ROW DELETION POLICY (OLDER_THAN(close_time, INTERVAL 90 DAY));

כשמגדירים מדיניות TTL בטבלת צמתים, צריך להגדיר איך המערכת מטפלת בקצוות קשורים כדי למנוע קצוות לא רצויים.

• לטבלאות קצה משולבות: אם טבלת קצה משולבת בטבלת הצמתים, אפשר להגדיר את קשר השילוב באמצעות ON DELETE CASCADE. כך מוודאים שכאשר TTL מוחק צומת, גם הקצוות המשולבים שמשויכים אליו נמחקים.

• לטבלאות קצה עם מפתחות זרים: אם טבלת קצה מפנה לטבלת הצומת עם מפתח זר, יש לכם שתי אפשרויות:

  • כדי למחוק קצוות באופן אוטומטי כשצומת ההפניה נמחק על ידי TTL, משתמשים ב-ON DELETE CASCADE במפתח הזר. כך נשמרת שלמות הנתונים.
  • כדי לאפשר לקצוות להישאר אחרי מחיקת הצומת שאליו הם מפנים (וכך ליצור קצה תלוי), צריך להגדיר את המפתח הזר כמפתח זר אינפורמטיבי.

בדוגמה הבאה, טבלת הקצה AccountTransferAccount כפופה לשתי מדיניות בנושא מחיקת נתונים:

• מדיניות TTL מוחקת רשומות העברה בנות יותר מעשר שנים.
• הסעיף ON DELETE CASCADE מוחק את כל רשומות ההעברה שמשויכות למקור כשחשבון המקור נמחק.

CREATE TABLE AccountTransferAccount (
  id               INT64 NOT NULL,
  to_id            INT64 NOT NULL,
  amount           FLOAT64,
  create_time      TIMESTAMP NOT NULL,
  order_number     STRING(MAX),
) PRIMARY KEY (id, to_id),
  INTERLEAVE IN PARENT Account ON DELETE CASCADE,
  ROW DELETION POLICY (OLDER_THAN(create_time, INTERVAL 3650 DAY));

מיזוג של טבלאות קלט של צמתים וקשתות

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

• פחות טבלאות: מצמצם את מספר הטבלאות בסכימה, וכך מפשט את ניהול הנתונים.

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

איך מגדירים צמתים וקשתות בטבלה אחת

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

• יצירה, עדכון או מחיקה של סכימת Spanner Graph.
• הוספה, עדכון או מחיקה של נתוני Spanner Graph.