אובייקטים מורכבים

יצירה

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

פעולת הרכבה

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

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

כשמבצעים הרכבה, חשוב לשים לב לנקודות הבאות:

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

האובייקט המורכב שמתקבל מההרכבה כולל את המאפיינים הבאים:

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

כשמשתמשים ב-gcloud storage כדי לבצע הרכבה של אובייקטים, לאובייקט שנוצר מוגדר Content-Type תואם לאובייקט Content-Type של אובייקט המקור הראשון.

מטא-נתונים של אובייקט מורכב

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

• לאובייקטים מורכבים אין שדה מטא-נתונים של גיבוב MD5.

  • המערכת מתעלמת מכל ערך MD5 שאתם מספקים כחלק מבקשת compose.

• ערך ה-ETag של אובייקט מורכב לא מבוסס על גיבוב MD5, וקוד הלקוח לא צריך להניח הנחות לגבי תגי ETag של אובייקטים מורכבים, למעט שהם משתנים בכל פעם שהאובייקט הבסיסי משתנה בהתאם למפרטי IETF של HTTP/1.1.

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

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

  • אם כותבים מחדש אובייקט מורכב למיקום אחר או לסוג אחסון (storage class) אחר, התוצאה תהיה אובייקט מורכב עם מספר רכיבים שהוא 1.

בדיקת תקינות של אובייקטים מורכבים

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

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

הערה: CRC32C לא מיועד להגנה מפני התקפות "man-in-the-middle", שבהן מישהו משנה את התוכן באופן שעדיין תואם לסיכום הביקורת (checksum) שצוין. ההגנה מפני מתקפות כאלו מתאפשרת באמצעות שימוש בחיבורי SSL בזמן העלאה והורדה של אובייקטים, שהוא ברירת המחדל של כלים וספריות רבים, כמו Google Cloud CLI.

צירוף ועריכה

אפשר להשתמש בפעולת הרכבה כדי לבצע פעולות של צירוף ועריכת אובייקטים.

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

לדוגמה, ב-CLI של gcloud, הפקודות הבאות מצרפות את המחרוזת new data לאובייקט קיים:

$ echo 'new data' | gcloud storage cp - gs://bucket/temporary_object
$ gcloud storage objects compose gs://bucket/existing_object gs://bucket/temporary_object \
    gs://bucket/existing_object --delete-source-objects

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

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

הקשרים של אובייקטים מורכבים

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

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

מפתחות הקשר ייחודיים

אם לאובייקטים במקור יש מפתחות הקשר ייחודיים, Cloud Storage מצרף ישירות את המפתחות האלה ואת הערכים התואמים שלהם לאובייקט היעד.

לדוגמה:

הקשרים של אובייקט מקור א': Department: Engineering, Status: Active

הקשרים של אובייקט המקור ב': Owner: m_jones, Version: 1.1

אחרי פעולת החיבור, לאובייקט היעד יש את ההקשרים המשולבים הבאים:

  {
    "contexts": {
      "custom": {
        "Department": {
          "value": "Engineering",
          "createTime": "2023-10-26T10:00:00.000Z",
          "updateTime": "2023-10-26T10:00:00.000Z"
        },
        "Status": {
          "value": "Active",
          "createTime": "2023-10-26T10:00:00.000Z",
          "updateTime": "2023-10-26T10:00:00.000Z"
        },
        "Owner": {
          "value": "m_jones",
          "createTime": "2023-10-26T10:00:00.000Z",
          "updateTime": "2023-10-26T10:00:00.000Z"
        },
        "Version": {
          "value": "1.1",
          "createTime": "2023-10-26T10:00:00.000Z",
          "updateTime": "2023-10-26T10:00:00.000Z"
        }
      }
    }
  }
  

מפתחות הקשר כפולים

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

לדוגמה, נניח שאובייקטים של מקור מעובדים בסדר הבא:

1. אובייקט מקור א'

2. אובייקט מקור ב'

הקשרים של אובייקט מקור א': Version: 1.0, ReleaseDate: 2024-01-15

הקשרים של אובייקט המקור ב': Version: 1.1, Owner: m_jones

לשני אובייקטי המקור יש מפתח Version, אבל לאובייקט א' יש Version: 1.0 ולאובייקט ב' יש Version: 1.1. מכיוון ש-Cloud Storage מעבד את אובייקט המקור ב' אחרי אובייקט המקור א', הערך Version של אובייקט המקור ב' מקבל קדימות והערך הסופי הוא 1.1.

אובייקט היעד משלב את ההקשרים האלה באופן הבא:

  {
    "contexts": {
      "custom": {
        "Version": {
          "value": "1.1",
          "createTime": "2025-01-01T00:00:00.000Z",
          "updateTime": "2025-01-01T00:00:00.000Z"
        },
        "ReleaseDate": {
          "value": "2024-01-15",
          "createTime": "2025-01-01T00:00:00.000Z",
          "updateTime": "2025-01-01T00:00:00.000Z"
        },
        "Owner": {
          "value": "m_jones",
          "createTime": "2025-01-01T00:00:00.000Z",
          "updateTime": "2025-01-01T00:00:00.000Z"
        }
      }
    }
  }
  

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

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