על מנת לתמוך בתרחישים נפוצים, כמו הגדרת אורך חיים (TTL) לאובייקטים, שמירת גרסאות לא עדכניות של אובייקטים או 'שדרוג לאחור' של סוג האחסון של אובייקטים כדי לחסוך בעלויות, Cloud Storage כולל את התכונה 'ניהול מחזור חיים של אובייקטים'.
דף זה מתאר את התכונה ואת האפשרויות הזמינות בעת השימוש בה. למידע על הפורמט הכללי של קובץ התצורה של מחזור חיים, ראו ייצוג של משאבי קטגוריה עבור JSON או פורמט התצורה של מחזור החיים עבור XML.
מבוא
על מנת להשתמש בתכונה 'ניהול מחזור חיים של אובייקטים', מבצעים הגדרה של מחזור חיים שחייב להיותמוגדר בקטגוריה. ההגדרה כוללת קבוצת כללים החלים על האובייקטים הקיימים והעתידיים בקטגוריה. כשאובייקט עומד בקריטריונים של אחד מהכללים, Cloud Storage מבצע עליו באופן אוטומטי פעולה מוגדרת. הנה כמה תרחישים לדוגמה:
- שדרוג לאחור של סוג האחסון של אובייקטים מלפני יותר מ-365 ימים ל-Coldline Storage.
- מחיקת אובייקטים שנוצרו לפני 1 בינואר 2019.
- שמירת 3 הגרסאות העדכניות בלבד של כל אובייקט, בקטגוריה עם הפעלת חלוקה לגרסאות.
הגדרה אישית של מחזור החיים
כל תצורה של ניהול מחזור חיים מכילה רשימת כללים. כל כלל מכיל פעולה אחת ותנאי אחד או יותר.
על מנת שהפעולה שבכלל תתבצע, האובייקט צריך לעמוד בכל התנאים המפורטים בכלל.
אם הוגדרו מספר כללים המכילים את אותה פעולה, הפעולה באובייקט תתבצע כשאותו אובייקט עומד בתנאים של כללכלשהו.
אם אובייקט יחיד עומד בו זמנית בתנאים של יותר מכלל אחד, Cloud Storage יבצע פעולה שמשויכת רק לאחד מהכללים, בהתאם לשיקולים הבאים:
- הפעולה
Delete
מקבלת עדיפות על כל פעולה מסוגSetStorageClass
. - הפעולה
SetStorageClass
שמעבירה את האובייקט לסיווג האחסון (storage class) עם התמחור הנמוך ביותר של אחסון במצב מנוחה מקבלת עדיפות.
לדוגמה, במקרה שיש כלל אחד שמשנה את המחלקה של האובייקט ל-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
בשילוב עם תנאים אחרים, תתקבל הודעת שגיאה.
תנאים במחזור החיים
כלל במחזור חיים כולל תנאים שאובייקט יש לעמוד בהם לפני שהפעולה המוגדרת בכלל מתרחשת על האובייקט. הכללים של מחזור החיים תומכים בתנאים הבאים:
age
createdBefore
customTimeBefore
daysSinceCustomTime
daysSinceNoncurrentTime
isLive
matchesStorageClass
matchesPrefix
וmatchesSuffix
noncurrentTimeBefore
numNewerVersions
כל התנאים הם אופציונליים, אבל נדרש לפחות תנאי אחד. במקרה שמנסים לקבוע הגדרות לא חוקיות של מחזור החיים, למשל על ידי שימוש בפעולה או בתנאי שלא קיימים, תקבלו את התשובה עם השגיאה 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 לפי בחירתכם. שימו לב שבתכונה הזו לא מתועד מי ביצע את הפעולות.
המאמרים הבאים
- הפעלת ניהול מחזור החיים של אובייקטים.
- דוגמאות להגדרות של מחזור חיים.
- סקירת הפורמט הכללי של הגדרת מחזור חיים בבקשות API ב-JASON ובבקשות API ב-XML.