סקירה כללית של אורך חיים (TTL)

אורך החיים (TTL) מאפשר לכם להגדיר מדיניות למחיקה תקופתית של נתונים מטבלאות Spanner. הסרת נתונים לא נחוצים:

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

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

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

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

איך TTL עובד?

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

  • לכל טבלה יכולה להיות מדיניות משלה.
  • אפשר לציין לכל טבלה רק מדיניות אחת של TTL.
  • הגדרת ה-TTL שונה עבור מסדי נתונים עם ניב GoogleSQL ועבור מסדי נתונים עם ניב PostgreSQL.
  • מדיניות ה-TTL לא מוחקת שורות שחותמת הזמן שלהן מוגדרת ל-NULL.
  • נתונים שנוספו עם חותמות זמן שתוקפן פג מנוקים כשהם מזוהים במחזור המחיקה הבא של TTL.

‫TTL עם GoogleSQL

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

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

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

הוראות מפורטות ליצירת המדיניות בנושא מחיקת נתונים של שורות ב-GoogleSQL מופיעות במאמר יצירת מדיניות TTL.

‫TTL עם PostgreSQL

ב-PostgreSQL, בעלי מסד נתונים יכולים להשתמש בסעיף TTL INTERVAL בהצהרה CREATE TABLE או ALTER TABLE כדי להגדיר המדיניות בנושא מחיקת נתונים.

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

הסעיף צריך להניב מספר שלם של ימים. לדוגמה, מותר להשתמש ב-'3 DAYS' וב-'4 DAYS 2 MINUTES - 2 MINUTES', אבל אסור להשתמש ב-'4 DAYS 3 MINUTES', ומוחזרת שגיאה. אי אפשר להשתמש במספרים שליליים.

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

הוראות ליצירת מדיניות למחיקת שורות ב-PostgreSQL מופיעות במאמר יצירת מדיניות TTL.

גיבויים ו-TTL

שחזור גיבוי

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

עקביות הנתונים

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

ביצוע בקרה

‫TTL תומך בביקורת של המחיקות שלו באמצעות סנכרון שינויים בזרמי נתונים. ברשומות של נתוני סנכרון שינויים בזרמי נתונים שמתעדים שינויים ב-TTL במסד נתונים, השדה transaction_tag מוגדר לערך RowDeletionPolicy והשדה is_system_transaction מוגדר לערך true. לאחר מכן, קוראי סנכרון שינויים בזרמי נתונים יכולים לסנן את כל רשומות ה-TTL, או את כל הרשומות חוץ מרשומות ה-TTL, בהתאם לתרחיש השימוש שלהם. דוגמה לשימוש ב-Beam לסינון לפי תגי עסקאות

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