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

יצירה

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

פעולת הרכבה

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

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

כשמבצעים הרכבה:

  • אין השפעה על אובייקטי המקור.
  • אפשר להשתמש ב-1 עד 32 אובייקטי מקור.
  • אובייקטי מקור יכולים בעצמם להיות אובייקטים מורכבים.

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

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

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

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

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

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

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

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

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

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

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

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

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

צירוף ועריכה מוגבלים

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

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

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

$ echo 'new data' | gcloud storage cp - gs://bucket/temporary_object
$ gcloud storage objects compose gs://bucket/object_to_append gs://bucket/temporary_object \
    gs://bucket/object_to_append
$ gcloud storage rm gs://bucket/temporary_object

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

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

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

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

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

דוגמה:

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

ההקשרים של אובייקט המקור B: 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"
        }
      }
    }
  }

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

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

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

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

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

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

ההקשרים של אובייקט המקור B: 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"
        }
      }
    }
  }

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