תצוגות מהותיות רציפות

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

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

הנתונים בתצוגה מהותית רציפה כוללים:

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

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

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

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

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

אפשר ליצור תצוגה מהותית רציפה באמצעות Google Cloud CLI, עורך השאילתות של Bigtable Studio במסוף Google Cloud או ספריות הלקוח של Bigtable ל-Java ול-Go.

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

מידע נוסף זמין במאמר קריאה מתצוגה מהותית רציפה.

מתי כדאי להשתמש בתצוגות מהותיות רציפות

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

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

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

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

מתי כדאי להשתמש במונים

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

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

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

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

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

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

כדאי להשתמש בשילוב של מונים ותצוגות מהותיות רציפות במקרים כמו:

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

הקצאת משאבים וביצועים

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

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

תצוגות מהותיות רציפות נכללות במגבלה של 1,000 טבלאות לכל מכונה.

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

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

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

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

תהליך היצירה של תצוגות מהותיות רציפות ב-Bigtable.
תרשים 1. תהליך היצירה של תצוגות מהותיות רציפות ב-Bigtable (אפשר ללחוץ כדי להגדיל).

לדוגמה, נניח שטבלת המקור מכילה שורות עם מפתחות לפי התבנית advertiser_id#region#ad_id וקבוצת עמודות אחת, data, שכוללת מגדיר עמודה spend_usd עם נתונים מספריים שמייצגים את הוצאות הפרסום:

מפתח שורה data:spend_usd
adv1#us-east#ad1 100
adv1#us-west#ad2 150
adv2#us-east#ad3 200

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

SELECT
          SPLIT(_key, "#")[SAFE_OFFSET(0)] AS advertiser_id,
          count(*) AS count,
          sum(cast(cast(data['spend_usd'] as string) as int64)) as sum_spend
        FROM `$0`
        GROUP BY advertiser_id

מכיוון ש-Bigtable מתרחב באופן ליניארי, אשכול של 175 צמתים מעבד 2TB של נתונים בערך ב-6 שעות ו-10TB בערך ב-30 שעות, בהנחה שלנתונים יש צורה דומה. כדי לקצר את הזמן שנדרש לאכלוס הראשוני, אתם יכולים להוסיף זמנית עוד צמתים לאשכול, או אם אתם משתמשים בהתאמה אוטומטית לעומס, להגדיל זמנית את מספר הצמתים המקסימלי.

פונקציות SQL לא דטרמיניסטיות

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

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

אחסון

בכל תצוגה מהותית רציפה, Bigtable שומר את הנתונים הבאים:

  • הנתונים בתצוגה המהותית הרציפה
  • אחסון ביניים

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

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

אחסון של תצוגה מהותית רציפה

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

אחסון ביניים

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

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

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

רפליקציה

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

עלויות

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

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

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

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

מדדים

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

מדד תיאור
materialized_view/max_delay הגבול העליון של עיכוב העיבוד של התצוגה המהותית הרציפה
materialized_view/storage כמות הנתונים שמשמשים לאחסון של התצוגה המהותית הרציפה, בבייטים
materialized_view/intermediate_storage כמות הנתונים שמשמשים לעיבוד ביניים של התצוגה המהותית הרציפה, בבייטים
table/materialized_view_intermediate_storage כמות הנתונים שמשמשים לעיבוד ביניים של תצוגות מהותיות רציפות שמוגדרות בטבלה הזו
materialized_view/user_errors מספר השגיאות מנתוני המשתמשים בתצוגה המהותית הרציפה. שגיאות של משתמשים מונעות את הפצת הנתונים לתצוגה המפורטת.
materialized_view/system_errors מספר השגיאות מהמערכת בתצוגה המהותית הרציפה

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

במאמר סקירה כללית על שאילתות וצפייה ביומנים מוסבר איך מתחילים להשתמש ב-Cloud Logging.

מגבלות

  • אפשר ליצור עד 50 תצוגות מהותיות רציפות לכל מכונה.
  • אפשר ליצור עד 5 תצוגות מהותיות רציפות לכל טבלה. במקרה הצורך, אפשר לבקש להגדיל את המגבלה הזו באמצעות פנייה אל Cloud Customer Care.
  • כשיוצרים תצוגה בלי לציין _key, העמודות שנבחרו בטבלת המקור לא יכולות להיות NULL. מידע נוסף זמין במאמר מפתחות שורות שמוגדרים על ידי משפט GROUP BY או ORDER BY.
  • אי אפשר לשנות את שאילתת ה-SQL שמגדירה תצוגה מהותית רציפה. צריך למחוק את התצוגה המהותית הרציפה וליצור תצוגה חדשה עם השינויים.
  • אי אפשר ליצור תצוגה מהותית רציפה מתצוגה מהותית רציפה אחרת או מתצוגה לוגית.
  • השאילתה שמגדירה תצוגה מהותית רציפה לא יכולה להשתמש ב-SELECT *.
  • אי אפשר להגדיר מדיניות איסוף אשפה לתצוגה מהותית רציפה. כל שמירת הנתונים כפופה למדיניות מנגנון איסוף הזבל של טבלת המקור, ומנגנון איסוף הזבל של המקור משתקף באופן אוטומטי בתצוגה המהותית הרציפה.
  • אי אפשר ליצור תצוגות מהותיות רציפות בטבלאות עם פירוט חותמות זמן במיקרו-שניות.

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