שימוש בתצוגות מהותיות

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

שאילתות על תצוגות מהותיות

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

התפקידים הנדרשים

כדי לקבל את ההרשאות שנדרשות להפעלת שאילתה בתצוגה חומרית, צריך לבקש מהאדמין להקצות לכם את תפקיד ה-IAM‏ BigQuery Data Viewer (roles/bigquery.dataViewer) בטבלת הבסיס של התצוגה החומרית ובתצוגה החומרית עצמה. כדי לקרוא הסבר על מתן תפקידים, ראו איך מנהלים את הגישה ברמת הפרויקט, התיקייה והארגון.

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

ההרשאות הנדרשות

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

  • bigquery.tables.get
  • bigquery.tables.getData

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

ההרשאות האלה נדרשות כדי שהשאילתות ייהנו מהתאמה חכמה.

מידע נוסף על תפקידי IAM ב-BigQuery זמין במאמר מבוא ל-IAM.

עדכונים מצטברים

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

אם בוצעו עדכונים או מחיקות במסד הנתונים הטבלאי מאז הרענון האחרון, או אם מסדי הנתונים הטבלאיים של התצוגה המהותית בצד שמאל של JOIN השתנו, BigQuery לא משתמש בעדכונים מצטברים, אלא חוזר אוטומטית לשאילתה המקורית. מידע נוסף על איחודים ותצוגות חומריות זמין במאמר איחודים. אלה דוגמאות לפעולות Google Cloud ב-API, בכלי שורת הפקודה של BigQuery ובמסוף שיכולות לגרום לעדכון או למחיקה:

  • פקודות בשפת טיפול בנתונים (DML) UPDATE, MERGE או DELETE
  • חיתוך
  • תוקף המחיצות

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

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

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

יישור מחיצות

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

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

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

בתצוגות חומריות מצטברות עם חלוקה למחיצות שמשתמשות ב-UNION ALL, כל טבלאות הבסיס צריכות להיות עם אותן הגדרות של תאריך התפוגה של המחיצה (TTL), כדי לשמור על התאמה בין המחיצות.

כוונון חכם

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

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

אין תמיכה בהתאמה חכמה במקרים הבאים:

דוגמאות להתאמה חכמה

דוגמה לשאילתה של תצוגה מהותית:

SELECT
  store_id,
  CAST(sold_datetime AS DATE) AS sold_date
  SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
  CAST(sold_datetime AS DATE) >= '2021-01-01' AND
  promo_id IS NOT NULL
GROUP BY 1, 2

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

שאילתה לשכתב? סיבה
SELECT
SUM(net_paid) AS sum_paid,
SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		לא התצוגה חייבת לכלול את כל העמודות שנקראות. התצוגה לא כוללת את 'SUM(net_paid)'.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL 		כן
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
customer_id = 12345 		לא התצוגה חייבת לכלול את כל העמודות שנקראות. התצוגה לא כוללת את הערך customer.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
sold_datetime= '2021-01-01' AND
promo_id IS NOT NULL
 לא התצוגה חייבת לכלול את כל העמודות שנקראות. ‫'sold_datetime' הוא לא פלט (אבל 'CAST(sold_datetime AS DATE)' הוא כן).
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id IS NOT NULL AND
store_id = 12345		 כן
‪SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2021-01-01' AND
promo_id = 12345 		לא התצוגה חייבת לכלול את כל השורות שנקראות. המאפיין promo_id לא מופיע בפלט, ולכן אי אפשר להחיל על התצוגה את המסנן המגביל יותר.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE CAST(sold_datetime AS DATE) >= '2020-01-01'
 לא התצוגה חייבת לכלול את כל השורות שנקראות. המסנן של התצוגה המפורטת הוא לתאריכים משנת 2021 ואילך, אבל השאילתה קוראת תאריכים משנת 2020.
SELECT SUM(net_profit) AS sum_profit
FROM dataset.store_sales
WHERE
CAST(sold_datetime AS DATE) >= '2022-01-01' AND
promo_id IS NOT NULL 		כן

הסבר על שאילתה שנכתבה מחדש

כדי להבין אם שאילתה נכתבה מחדש על ידי כוונון חכם כדי להשתמש בתצוגה חומרית, בודקים את תוכנית לביצוע שאילתה. אם השאילתה נכתבה מחדש, תוכנית לביצוע שאילתה תכלול שלב READ my_materialized_view, כאשר my_materialized_view הוא השם של התצוגה החומרית שבה נעשה שימוש. כדי להבין למה שאילתה לא השתמשה בתצוגה חומרית, אפשר לקרוא את המאמר הסבר על דחייה של תצוגות חומריות.

למה תצוגות חומריות נדחו

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

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

  • שאילתה ישירה של התצוגה המהותית
  • שאילתה עקיפה שבה התאמה חכמה עשויה לבחור להשתמש בתצוגה החומרית

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

שאילתה ישירה של תצוגות מהותיות

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

  1. פועלים לפי השלבים במאמר מעקב אחרי השימוש בתצוגה חומרית ומחפשים את התצוגה החומרית הרלוונטית בשדה materialized_view_statistics של השאילתה.
  2. אם chosen מופיע בסטטיסטיקות והערך שלו הוא TRUE, השאילתה משתמשת בתצוגה החומרית.
  3. צריך לעיין בשדה rejected_reason כדי להבין מה צריך לעשות. ברוב המקרים, אפשר לרענן ידנית את התצוגה החומרית או לחכות לרענון האוטומטי הבא.

שאילתה עם כוונון חכם

  1. פועלים לפי השלבים במאמר מעקב אחרי השימוש בתצוגה חומרית ומאתרים את התצוגה החומרית הרלוונטית בmaterialized_view_statistics של השאילתה.
  2. כדאי לעיין בrejected_reason כדי להבין מה השלבים הבאים. לדוגמה, אם הערך של rejected_reason הוא COST, המשמעות היא שהתכונה 'התאמה חכמה' זיהתה מקורות נתונים יעילים יותר לעלות ולביצועים.
  3. אם התצוגה החומרית לא מופיעה, מנסים לבצע שאילתה ישירה של התצוגה החומרית ופועלים לפי השלבים במאמר שאילתה ישירה של תצוגות חומריות.
  4. אם השאילתה הישירה לא משתמשת בתצוגה החומרית, הצורה של התצוגה החומרית לא תואמת לשאילתה. מידע נוסף על כוונון חכם ועל אופן השכתוב של שאילתות באמצעות תצוגות חומריות מופיע במאמר דוגמאות לכוונון חכם.

שאלות נפוצות

מתי כדאי להשתמש בשאילתות מתוזמנות ומתי בתצוגות חומריות?

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

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

ככלל, מומלץ להשתמש בתצוגות חומריות כשאפשר, ואם אתם לא מריצים חישובים מורכבים באופן שרירותי.

חלק מהשאילתות על תצוגות חומריות פועלות לאט יותר מאותן שאילתות על טבלאות חומריות שנוצרו באופן ידני. למה זה קורה?

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

נבחן את התרחיש הבא:

CREATE MATERIALIZED VIEW my_dataset.my_mv AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

CREATE TABLE my_dataset.my_materialized_table AS
SELECT date, customer_id, region, SUM(net_paid) as total_paid
FROM my_dataset.sales
GROUP BY 1, 2, 3;

לדוגמה, השאילתה הבאה:

‫
  SELECT * FROM my_dataset.my_mv LIMIT 10
 בדרך כלל פועלת לאט יותר מהשאילתה הזו:
‫
  SELECT * FROM my_dataset.my_materialized_table LIMIT 10
 כדי לספק תוצאות עדכניות באופן עקבי, BigQuery צריך לשלוח שאילתה לשורות חדשות במסד הנתונים הטבלאי ולמזג אותן בתצוגה החומרית לפני החלת התנאי 'LIMIT 10'. כתוצאה מכך, האיטיות נמשכת גם אם התצוגה החומרית מעודכנת לחלוטין.

מצד שני, צבירות של תצוגות חומריות הן בדרך כלל מהירות כמו שאילתות נגד הטבלה החומרית. לדוגמה:

‫
  SELECT SUM(total_paid) FROM my_dataset.my_mv WHERE date > '2020-12-01'
 הקצב צריך להיות מהיר כמו בדוגמה הזו: 
  SELECT SUM(total_paid) FROM my_dataset.my_materialized_table WHERE date > '2020-12-01'