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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

מתי כדאי להשתמש בדלפקים

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

התהליך של יצירת תצוגות מהותיות רציפות ב-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 בכשש שעות, ונתונים בנפח ‎10TB בכ-30 שעות, בהנחה שלנתונים יש צורה דומה. כדי לקצר את הזמן שנדרש לאכלוס הראשוני, אפשר להוסיף זמנית עוד צמתים לאשכול, או אם אתם משתמשים בהתאמה אוטומטית לעומס, להגדיל זמנית את מספר הצמתים המקסימלי.

אחסון

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

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

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

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

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

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

אחסון ביניים

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

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

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

שכפול

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

עלויות

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

  • אחסון – אתם מחויבים על אחסון הנתונים בתצוגה המגובשת הרציפה ועל אחסון ביניים. מידע נוסף זמין במאמר בנושא אחסון.
  • ‫Compute – הסנכרון המתמשך של טבלת המקור והתצוגה הרציפה המגובה בחומרים דורשים עיבוד 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.
  • אי אפשר לשנות את שאילתת ה-SQL שמגדירה תצוגה חומרית רציפה. צריך למחוק את התצוגה המגולמת הרציפה וליצור חדשה עם השינויים.
  • אי אפשר ליצור תצוגה מהותית רציפה של תצוגה מהותית רציפה אחרת או של תצוגה לוגית.
  • אי אפשר להגדיר מדיניות של איסוף נתונים מיותרים לתצוגה רציפה של נתונים חומריים. כל שמירת הנתונים נשלטת על ידי מדיניות איסוף האשפה עבור טבלת המקור ואיסוף האשפה של המקור משתקף אוטומטית בתצוגה הממומשת הרציפה.

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