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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

יישור של מחיצה

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

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

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

כוונון חכם

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

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

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

• תצוגות מהותיות שמפנות לתצוגות לוגיות.
• תצוגות חומריות עם union all או left outer join.
• תצוגות מהותיות לא מצטברות.
• תצוגות חומריות שמפנות לטבלאות עם הפעלה של לכידת נתוני שינוי.

דוגמאות לשימוש בהתאמה חכמה

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

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'