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

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

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

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

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

הגדרת חלון הזמן של התכונה 'חזרה בזמן'

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

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

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

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

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

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

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 של קבוצת נתונים שנמחקה עד שמבטלים את המחיקה שלה.

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

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

אם בטבלה יש או היו כללי מדיניות גישה ברמת השורה, רק חשבון משתמש שקיבל את ההרשאה הבאה של ניהול זהויות והרשאות גישה (IAM) יכול לגשת לנתונים ההיסטוריים של הטבלה:

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

התפקידים המוגדרים מראש הבאים ב-IAM כוללים את ההרשאה bigquery.rowAccessPolicies.overrideTimeTravelRestrictions:

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

אפשר גם לתת את ההרשאה bigquery.rowAccessPolicies.overrideTimeTravelRestrictions באמצעות תפקיד בהתאמה אישית.

  • מריצים את הפקודה הבאה כדי לקבל את הזמן המקביל בראשית זמן יוניקס (Unix epoch) על ידי העברת חותמת הזמן ב-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

Fail-safe

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

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

כשמבצעים את הפעולות הבאות, אפשר לשחזר את הנתונים שהוחלפו או הוסרו באמצעות חלון הזמן של המסע בזמן. אחרי שחלון הזמן של Time Travel מסתיים, הנתונים נכנסים לתקופת Fail-safe לזמן שחזור מורחב:

  • מחיקה או החלפה של טבלה: כשמוחקים טבלה או כשהנתונים שלה מוחלפים במלואם (לדוגמה, באמצעות מאפיין הכתיבה WRITE_TRUNCATE במשימת טעינה או באמצעות ההצהרה CREATE OR REPLACE TABLE ), התוכן הקודם של הטבלה נשמר.
  • מחיקה או תפוגה של מחיצה: אם מחיצה ספציפית נמחקת או שתוקפה פג מטבלה עם מחיצות, הנתונים ששייכים למחיצה הספציפית הזו נשמרים. מחיצות אחרות בטבלה לא מושפעות. אי אפשר לשחזר מחיצה ספציפית, ולכן צריך לשחזר את כל הטבלה מחותמת זמן שלפני המחיקה או התפוגה של המחיצה. אם בטבלה המקורית יש תפוגה של מחיצה, ההגדרה הזו מועתקת לטבלה המשוחזרת. כדי לבצע שאילתה במחיצות משוחזרות שנוצרו לפני תאריך התפוגה של המחיצה, צריך לעדכן את תאריך התפוגה של המחיצה בטבלה המשוחזרת.

שחזור נתונים מאחסון בטוח

אי אפשר לשלוח שאילתות לנתונים באחסון בטוח ישירות, ואי אפשר להעתיק טבלה מאחסון בטוח עד ש-Cloud Customer Care מעניק גישה זמנית לשחזור בטוח של מערך הנתונים. כדי לשחזר טבלה מאחסון Fail-safe, פנו ל-Cloud Customer Care ובקשו גישה לשחזור Fail-safe של קבוצת הנתונים. לאחר מכן, שחזרו את הטבלה בעצמכם על ידי הפעלת משימה להעתקת טבלה עם מעטר חותמת זמן של @TIME.

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

  • זמני העתקה ארוכים יותר וזמני קצובים לתפוגה: שחזור טבלה בגודל של כמה טרה-בייטים או טבלה עם הרבה מחיצות מאחסון בטוח יכול להימשך הרבה יותר זמן מאשר העתקה רגילה של טבלה. יכול להיות שייווצר מצב שבו משימת העתקה אחת תסתיים לפני הזמן או תיכשל עם שגיאה פנימית זמנית לפני שכל בלוקי האחסון ישוחזרו.
  • התקדמות הדרגתית בניסיונות חוזרים: ההתקדמות של השחזור נשמרת באופן הדרגתי. כל בלוקי האחסון ששוחזרו לפני שהזמן הקצוב לתפוגה של משימת ההעתקה חלף או שהמשימה נכשלה, נשארים משוחזרים. אם הפקודה bq cp נכשלת, נסו שוב להריץ את הפקודה עם אותה טבלת מקור ואותו מעצב חותמת זמן @TIME. בכל ניסיון חוזר, המערכת מדלגת על הבלוקים שכבר שוחזרו וממשיכה לשחזר את שאר הנתונים עד שההעתקה מצליחה.
  • חלון זמן לשחזור רגיש לזמן: חשוב לפנות לCloud Customer Care בהקדם האפשרי במהלך תקופת ההגנה של שבעה ימים, במיוחד אם מדובר בטבלאות גדולות, כדי שיהיה לכם מספיק זמן להפעיל ניסיונות חוזרים לפני שתקופת ההגנה תסתיים.

חיוב

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

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

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

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

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

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

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

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

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

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

מגבלות

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

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