שמירת נתונים עם תכונות של חזרה בזמן ומניעת כשל

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

מסע בזמן ושמירת נתונים

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

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

הגדרת חלון הזמן של הנסיעה בזמן

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

הגדרת חלון הזמן של Time Travel ברמת הפרויקט

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

הגדרת חלון הזמן של Time Travel ברמת מערך הנתונים

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

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

Table ID was created at time which is
before its allowed time travel interval timestamp. Creation
time: timestamp

איך פועל המסע בזמן

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

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

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

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

לכן, שינוי של תא אחד יכול לגרום לשליחה של יותר נתונים ל-time travel מאשר רק גודל השינוי.

איך חלון הזמן של Time Travel משפיע על שחזור של טבלה ושל מערך נתונים

טבלה או מערך נתונים שנמחקו משתמשים במשך הזמן של חלון הנסיעה בזמן שהיה בתוקף בזמן המחיקה.

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

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

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

מסע בזמן וגישה ברמת השורה

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

נדרשת ההרשאה הבאה בניהול הזהויות והרשאות הגישה (IAM):

הרשאה משאב
bigquery.rowAccessPolicies.overrideTimeTravelRestrictions הטבלה שאליה מתבצעת גישה לנתונים היסטוריים

התפקיד הבא ב-BigQuery מספק את ההרשאה הנדרשת:

תפקיד משאב
roles/bigquery.admin הטבלה שאליה מתבצעת גישה לנתונים היסטוריים

אי אפשר להוסיף את ההרשאה bigquery.rowAccessPolicies.overrideTimeTravelRestrictions לתפקיד בהתאמה אישית.

  • מריצים את הפקודה הבאה כדי לקבל את הזמן המקביל של מערכת Unix על ידי העברת חותמת הזמן של UTC:

    date -d '2023-08-04 16:00:34.456789Z' +%s000

  • מחליפים את הזמן בפורמט UNIX epoch ‏1691164834000 שהתקבל מהפקודה הקודמת בכלי שורת הפקודה של BigQuery. מריצים את הפקודה הבאה כדי לשחזר עותק של הטבלה שנמחקה deletedTableID בטבלה אחרת restoredTable, באותו מערך נתונים myDatasetID:

    bq cp myProjectID:myDatasetID.deletedTableID@1691164834000 myProjectID:myDatasetID.restoredTable

מנגנון למניעת כשלים

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

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

אי אפשר לשלוח שאילתות או לשחזר נתונים ישירות באחסון בטוח. כדי לשחזר נתונים מאחסון בטוח מפני כשלים, צריך לפנות אל Cloud Customer Care.

חיוב

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

אם הגדרתם את מודל החיוב של האחסון לשימוש בבייטים לוגיים, העלויות הכוללות של האחסון לשימוש בתכונות Time Travel ו-Fail-safe Storage כלולות בתעריף הבסיסי שחויבתם עליו.

בטבלה הבאה מוצגת השוואה בין עלויות האחסון הפיזי והלוגי:

מודל חיוב על מה משלמים?
אחסון פיזי (דחוס)
  • תשלום על בייטים פעילים
  • משלמים על אחסון לטווח ארוך
  • תשלום על אחסון של נסיעות בזמן
  • אתם משלמים על אחסון בטוח
אחסון לוגי (לא דחוס) (הגדרת ברירת מחדל)
  • תשלום על אחסון פעיל
  • משלמים על אחסון לטווח ארוך
  • לא משלמים על אחסון של נסיעות בזמן
  • לא משלמים על אחסון בטוח

אם אתם משתמשים באחסון פיזי, תוכלו לראות את מספר הבייטים שמשמשים את התכונות 'חזרה בזמן' ו'מצב בטוח' בעמודות TIME_TRAVEL_PHYSICAL_BYTES ו-FAIL_SAFE_PHYSICAL_BYTES בתצוגות TABLE_STORAGE ו-TABLE_STORAGE_BY_ORGANIZATION. דוגמה לשימוש באחת מהתצוגות האלה כדי להעריך את העלויות מופיעה במאמר בנושא תחזית החיובים על אחסון.

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

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

דוגמה לשמירת נתונים

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

יום 0 היום הראשון היום השני יום 3 יום 4 יום 5 יום 6 יום 7 יום 8 יום 9 יום 10 יום 11 יום 12 יום 13 יום 14 יום 15
אחסון פעיל 200 150 150 150 150 150 150 150 150 150 150 150 150 150 150 150
אחסון של נסיעות בזמן 50 50 50 50 50 50 50
אחסון בטוח 50 50 50 50 50 50 50

מחיקת נתונים מאחסון פיזי לטווח ארוך פועלת באותו אופן.

מגבלות

אחזור נתונים באמצעות 'מסע בזמן' כפוף למגבלות הבאות:

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