קבצים של פידים מחולקים

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

מתי כדאי להשתמש בחלוקה לפלחים

  • הפיד גדול מ-200MB בקובץ אחד (אחרי דחיסת gzip).

    • דוגמה: פיד הזמינות שנוצר הוא בנפח 1GB. צריך לחלק את הנתונים ל-5 קובצי משנה (או קטעים) נפרדים לפחות.

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

    • דוגמה: לשותף יש מלאי שטחי פרסום בארה"ב ובאיחוד האירופי שנמצאים במערכות נפרדות. הפיד יכול להיווצר עם 2 קבצים (או פלחים), אחד לארה"ב ואחד לאיחוד האירופי, עם אותם nonce ו-generation_timestamp.

הנחיות כלליות

  • כל שבר לא יכול לחרוג מ-200MB לקובץ אחד (אחרי דחיסת gzip).
  • מומלץ ליצור עד 20 פלחים לכל פיד. אם יש לכם הצדקה עסקית לצורך סכום גבוה יותר, תוכלו לפנות לתמיכה לקבלת הוראות נוספות.
  • יש לשלוח רשומות בודדות (למשל, אובייקט Merchant אחד) בשריד אחד, ואי אפשר לפצל אותן לכמה שברי מידע. עם זאת, אין צורך לשלוח אותם באותה shard_number בפלחים של פידים עתידיים.
  • כדי לשפר את הביצועים, כדאי לפצל את הנתונים באופן שווה בין הפלחים, כך שכל הקבצים המפוצלים יהיו בגודל דומה.

איך לפצל פידים

כדי לפצל את פיד האירועים, אפשר לפצל קובץ JSON אחד לקובצי JSON נפרדים עם אירועים לא חופפים, ולעדכן את קובץ ה-JSON של מתאר הקובץ ברשימת שמות קובצי ה-JSON.

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

דוגמה לחלוקה למקטעים

תיאור קובץ – event.feeddata.v1_1728306001.filedescriptor.json

{
  "generation_timestamp": 1728306001,
  "name": "event.feeddata.v1",
  "data_file": [
    "event.feeddata.v1_1728306001_001.json",
    "event.feeddata.v1_1728306001_002.json"
  ]
}

פסע 0 – event.feeddata.v1_1728306001_001.json

{
  "data": [
    {
      "id": "event-1",
      ...
    },
    {
      "id": "event-2",
      ...
    }
  ]
}

שריד 1 – event.feeddata.v1_1728306001_002.json

{
  "data": [
    {
      "id": "event-3",
      ...
    },
    {
      "id": "event-4",
      ...
    }
  ]
}

פלחים של מלאי שטחי פרסום שמנוהל על ידי שותפים

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

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

השותף יכול לפצל כל פיד לשני קבצים (או פלחים):

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

  1. קובעים לוח זמנים להעלאות ומגדירים כל מופע של מלאי שטחי הפרסום כך שיתאים ללוח הזמנים.
  2. מקצים מספרים ייחודיים של פלחים לכל מכונה (למשל: ארה"ב = N, האיחוד האירופי = N + 1). מגדירים את total_shards למספר הכולל של שברי המטא-נתונים.
  3. בכל שעה מתוזמנת להעלאה, צריך להחליט איזה generation_timestamp להשתמש בו. צריך להגדיר את כל שמות הקבצים כך שיכללו את אותם ערכים בשני השדות האלה, ולפרט את כל שמות הקבצים הצפויים בקובץ המתאר.
    • השדה generation_timestamp צריך לכלול תאריך נוכחי או תאריך מהזמן האחרון (רצוי חותמת הזמן של קריאת השותף במסד הנתונים)
  4. אחרי העלאת כל השברים, Google מקבצת את השברים באמצעות generation_timestamp ו-nonce.

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