ניהול מחזור חיים של אובייקטים

הגדרה דוגמאות להגדרות

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

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

מבוא

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

  • שדרוג לאחור של סוג האחסון של אובייקטים מלפני יותר מ-365 ימים ל-Coldline Storage.
  • מחיקת אובייקטים שנוצרו לפני 1 בינואר 2019.
  • שמירת 3 הגרסאות העדכניות בלבד של כל אובייקט, בקטגוריה עם הפעלת חלוקה לגרסאות.

הגדרה אישית של מחזור החיים

כל תצורה של ניהול מחזור חיים מכילה רשימת כללים. כל כלל מכיל פעולה אחת ותנאי אחד או יותר.

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

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

  • אם אובייקט יחיד עומד בו זמנית בתנאים של יותר מכלל אחד, Cloud Storage יבצע פעולה שמשויכת רק לאחד מהכללים, בהתאם לשיקולים הבאים:

    לדוגמה, במקרה שיש כלל אחד שמשנה את המחלקה של האובייקט ל-Nearline Storage, וכלל אחר שמשנה את המחלקה של האובייקט ל-Coldline Storage, אבל שני הכללים משתמשים באותו התנאי, המחלקה של האובייקט תמיד משתנה ל-Coldline Storage כשמתקיים התנאי.

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

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

    לדוגמה, במקרה שמשנים תנאי של age מ-10 ימים ל-20 ימים, אובייקט בן 11 ימים עשוי להימחק על ידי ניהול מחזור החיים של אובייקטים עד 24 שעות מאוחר יותר, בגלל הקריטריונים של את ההגדרה הישנה.

לתרחישים לדוגמה, ראה דוגמאות להגדרות של ניהול מחזור החיים של אובייקטים.

פעולות במחזור החיים

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

מקש Delete

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

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

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

SetStorageClass

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

ב-SetStorageClass יש תמיכה במעברים הבאים של סוגי אחסון:

סוג האחסון המקורי סוג האחסון החדש
אחסון עמיד בזמינות מופחתת (DRA) אחסון בקרבת מקום
אחסון ב-Coldline
אחסון בארכיון
אחסון רב-אזורי/אחסון אזורי1
אחסון רגיל, אחסון מרובה אזורים או אחסון אזורי אחסון ב-Nearline
אחסון ב-Coldline
אחסון בארכיון
Nearline Storage אחסון ב-Coldline storage
אחסון ב-Archive storage
Coldline Storage Archive Storage

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

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

בטל העלאות שאינן הושלמו

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

עם הפעולה הזו ניתן לך להשתמש רק בתנאים הבאים של מחזור החיים:

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

תנאים במחזור החיים

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

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

age

התנאי age מתקיים כשהמשאב מגיע לגיל שצוין (בימים). הגיל נמדד לפי מועד היצירה של המשאב.

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

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

לדוגמה, במקרה שמשאב נוצר ב-10.1.2022 בשעה 10:00 UTC (זמן אוניברסלי מתואם) והתנאי age הוא 10 ימים, התנאי מתקיים עבור המשאב בתאריך 20.1.2022 ב-10:00 UTC ואילך.

createdBefore

התנאי createdBefore מתקיים כשאובייקט נוצר לפני חצות בתאריך שצוין ב-UTC.

customTimeBefore

התנאי customTimeBefore מתקיים כשהחלק של התאריך במטא-נתונים של Custom-Time של אובייקט מוקדם יותר מהתאריך שצוין בתנאי הזה. התנאי הזה מוגדר באמצעות פורמט התאריך YYYY-MM-DD. הערך customTimeBefore אף פעם לא תואם לאובייקט שלא הוגדר לו מטא-נתונים של Custom-Time.

daysSinceCustomTime

התנאי daysSinceCustomTime מתקיים כשחלפו מספר הימים שצוין מאז התאריך והשעה שצוינו בשדה המטא-נתונים Custom-Time של האובייקט. לדוגמה, במקרה שCustom-Time של אובייקט הוא 2020-05-16T10:00:00Z והתנאי daysSinceCustomTime הוא 10 ימים, התנאי מתקיים עבור האובייקט בתאריך 26.5.2020 ב-10:00 UTC.

הערך daysSinceCustomTime אף פעם לא תואם לאובייקט שלא הוגדר לו מטא-נתונים של Custom-Time.

daysSinceNoncurrentTime

בדרך כלל משתמשים בתנאי daysSinceNoncurrentTime רק בשילוב עם יצירת גרסאות של אובייקטים. התנאי מתקיים כשחלפו מספר הימים שצוין מאז שהאובייקט הפך ללא עדכני, כי הגרסה הפעילה נמחקה או הוחלפה. לדוגמה, במקרה שאובייקט הוא לא עדכני ב-2020/07/08 15:00 UTC והתנאי daysSinceNoncurrentTime הוא 10 ימים, התנאי מתקיים עבור האובייקט בתאריך 2020 ואילך. /07/18 15:00 UTC.

isLive

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

matchesPrefix ו matchesSuffix

התנאים matchesPrefix ו-matchesSuffix מתקיימים כאשר ההתחלה או הסוף של שם האובייקט הם התאמה מדויקת בהתאם לאותיות רישיות (case-sensitive) לקידומת או לסיומת שצוינו. באפשרותך לציין כמה מחרוזות כרשימה (לדוגמה, "matchesSuffix": [".jpg", ".png"]).

כשמשתמשים ב-matchesPrefix, לא יש לכלול את / שקודם לשמות האובייקטים ברוב נתיבי הבקשות. לדוגמה, ב-Google Cloud CLI, הפורמט של הנתיב לאובייקט בקטגוריה דומה ל-gs://my_bucket/pictures/paris_2022.jpg. על מנת להתאים לאובייקט, יש להשתמש בתנאי כמו "matchesPrefix":["pictures/paris_"].

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

matchesStorageClass

התנאי matchesStorageClass מתקיים כשאובייקט בקטגוריה מאוחסן כסיווג האחסון (storage class) שצוין. ניתן לך להשתמש בערכים הבאים עבור matchesStorageClass: STANDARD, NEARLINE, COLDLINE, ARCHIVE, MULTI_REGIONAL, REGIONAL וגם DURABLE_REDUCED_AVAILABILITY.

באופן כללי, אם אתם מתכוונים להשתמש בתנאי matchesStorageClass באובייקטים רגילים של אחסון, יש לכלול גם את הפרטים הבאים:

  • במקרה שהקטגוריה נמצאת באזור, יש לכלול את הערכים REGIONAL ואת DURABLE_REDUCED_AVAILABILITY בתנאי.

  • במקרה שהקטגוריה נמצאת במספר אזורים או בשני אזורים, יש לכלול את הערכים MULTI_REGIONAL ו-DURABLE_REDUCED_AVAILABILITY בתנאי.

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

noncurrentTimeBefore

בדרך כלל משתמשים בתנאי noncurrentTimeBefore רק בשילוב עם יצירת גרסאות של אובייקטים. התנאי מתקיים עבור אובייקטים שהפסיקו להיות פעילים בתאריך שקודם לזה שצוין בתנאי הזה. התנאי מוגדר באמצעות פורמט התאריך YYYY-MM-DD. הערך noncurrentTimeBefore אף פעם לא תואם לאובייקט פעיל.

numNewerVersions

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

התנהגות מחזור החיים של אובייקט

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

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

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

SetStorageClassשיקולי עלות

בדומה לשינוי ידני של מחלקת האחסון של אובייקט, השימוש ב-SetStorageClass נחשב כפעולה ברמה A ומחויב לפי השיעור שנקבע על ידי היעד סוג האחסון (storage class).

בניגוד לשינוי ידני של סוג האחסון (storage class) של אובייקט, השימוש ב-SetStorageClass לא שכתוב אובייקט. כך יש יתרון תמחור מסוים לניהול מחזור החיים של אובייקטים:

  • לשינוי סוג האחסון אין דמי אחזור או עמלות מחיקה מוקדמת, גם אם האובייקט הוגדר במקור כ-Nearline Storage או כ-Coldline Storage.

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

לדוגמה, נניח שאתם מעלים אובייקט בתור Nearline Storage, ו-20 ימים לאחר מכן ההגדרות של מחזור החיים משנות את סיווג האחסון של האובייקט ל-Coldline Storage. שינוי זה לא כרוך בעמלות אחזור או בעמלות מחיקה מוקדמות. במקרה שתמחקו את האובייקט 60 יום אחרי השינוי של סוג האחסון, יחול רק חיוב מוקדם על מחיקה של 10 ימים, כי לאחסון ב-Coldline יש משך אחסון מינימלי של 90 יום, והאובייקט היה קיים במשך 80 יום בסך הכל.

לשם השוואה, נניח שאתם מעלים אובייקט כאחסון מסוג Nearline, ו-20 יום לאחר מכן משנים את סיווג האחסון באמצעות שכתוב (שוב ל-Coldline Storage). בעקבות השינוי הזה תצטרכו גם עמלת אחזור וגם חיוב על מחיקה לפני 10 ימים. במקרה שתמחק את האובייקט 60 יום אחרי השכתוב, יחול חיוב מוקדם על מחיקה תוך 30 יום.

שעת יצירת האובייקט

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

  • אובייקט אינו כפוף לכללי מחזור החיים עד לסיום ההעלאה שלו.
  • זמן היצירה של אובייקט מבוסס על מועד הסיום של ההעלאה. הדבר משפיע על התנאים במחזור החיים של age ושל createdBefore.
  • כשמגדירים Custom-Time לאובייקט, יש לעשות זאת בתחילת ההעלאה. במקרה שמגדירים Custom-Time על סמך מועד הבקשה, ייתכן שה-Custom-Time יהיה מוקדם בהרבה משעת היצירה של האובייקט. הדבר משפיע על התנאים במחזור החיים של customTimeBefore ושל daysSinceCustomTime.

מטא-נתונים של מועד התפוגה

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

במקרה שחסרים מטא-נתונים לגבי מועד התפוגה, זה לא בהכרח אומר שהאובייקט לא יימחק, אלא שאין מספיק מידע זמין על מנת לקבוע מתי או אם הוא יימחק. לדוגמה, במקרה שזמן היצירה של האובייקט הוא 2020/01/10 10:00 UTC והתנאי age מוגדר ל-10 ימים, זמן התפוגה של האובייקט הוא 2020/01/20 10:00 UTC. עם זאת, זמן התפוגה אינו זמין לאובייקט אם:

  • למעט matchesStorageClass, יש תנאים נוספים שצוינו בכלל Delete.

  • יש להשתמש בתנאי matchesStorageClass שלא כולל את סוג האחסון של האובייקט.

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

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

כשקובעים זמני תפוגה, חשוב לזכור:

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

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

אפשרויות למעקב אחר פעולות במחזור החיים

על מנת לעקוב אחרי פעולות ניהול מחזור החיים של Cloud Storage, ניתן להשתמש באחת מהאפשרויות הבאות:

  • שימוש ביומני השימוש ב-Cloud Storage. תכונה זו מתעדת גם את הפעולה וגם את האדם שביצע אותה. הערך GCS Lifecycle Management בשדה cs_user_agent של הרשומה ביומן מציין שהפעולה בוצעה על ידי Cloud Storage בהתאם להגדרה של מחזור החיים.

  • הפעלת האפשרות התראות Pub/Sub ל-Cloud Storage בקטגוריה שלכם. כשהפעולות האלה מתבצעות, התכונה הזו שולחת את ההתראות לנושא Pub/Sub לפי בחירתכם. שימו לב שבתכונה הזו לא מתועד מי ביצע את הפעולות.

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