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

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

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

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

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

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

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

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

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

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

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

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

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

כדי לוודא שהנתונים בתצוגה המפורטת הרציפה תמיד עדכניים, מומלץ להפעיל שינוי גודל אוטומטי של האשכולות במופע שמכיל את התצוגה המפורטת הרציפה. התכונה 'שינוי גודל אוטומטי' מוסיפה באופן אוטומטי מספיק צמתים כדי לטפל בתקורה של העיבוד, ואז מסירה אותם כשאין בהם יותר צורך. כך אפשר לוודא שיש מספיק קיבולת חישוב במהלך הביצוע של שאילתת ה-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(), כדי לסנן נתונים לפי האשכול שמבצע את העיבוד. מידע נוסף זמין במאמר בנושא Non-deterministic queries.

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

אחסון

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

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

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

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

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

תצוגה חומרית מתמשכת מכילה נתונים שמתקבלים משאילתת ה-SQL שעליה היא מבוססת. כלומר, היא מכילה ערכים מצטברים שמוגדרים על ידי פסקי aggregation בשאילתת ה-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 כדי לעקוב אחרי תצוגה חומרית מתמשכת, באמצעות המזהה של התצוגה החומרית המתמשכת במקום מזהה הטבלה. בפרט, תצוגות חומריות רציפות נכללות בפירוט של מדדי המעבד, שיכול לעזור לכם להבין את ההשפעה שלהן. מדדים של Bigtable לגבי בקשות לשנייה, חביון וקצב העברת נתונים נוצרים כשקוראים תצוגה חומרית רציפה באמצעות השיטה ReadRows של Data API. מידע נוסף זמין במאמר בנושא מדדים.

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

מגבלות

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

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