File del feed suddivisi

A seconda dell'inventario, potrebbe essere necessario eseguire lo sharding (o suddividere i feed in più file).

Quando utilizzare lo sharding

  • Il feed supera i 200 MB per 1 file (dopo la compressione gzip).

    • Esempio: il feed di disponibilità generato è di 1 GB. Deve essere suddiviso in almeno 5 file (o frammenti) separati.

  • L'inventario del partner è distribuito su sistemi e/o regioni, il che rende difficile la riconciliazione dell'inventario.

    • Esempio: il partner ha un inventario per gli Stati Uniti e per l'UE in sistemi distinti. Il feed può essere generato con 2 file (o shard), 1 per gli Stati Uniti e 1 per l'UE con gli stessi nonce e generation_timestamp.

Regole generali

  • Ogni frammento non può superare i 200 MB per 1 file (dopo la compressione gzip).
  • Consigliamo di non utilizzare più di 20 frammenti per feed. Se hai una motivazione commerciale che richiede più di questa cifra, contatta l'assistenza per ulteriori istruzioni.
  • I singoli record (ad esempio un oggetto Merchant) devono essere inviati in un singolo shard e non possono essere suddivisi in più shard. Tuttavia, non devono essere inviati nel frammento con lo stesso shard_number per i feed futuri.
  • Per migliorare le prestazioni, i dati devono essere suddivisi in modo uniforme tra i frammenti in modo che tutti i file suddivisi in frammenti abbiano dimensioni simili.

Come suddividere i feed

Puoi suddividere il feed di eventi dividendo un singolo file JSON in file JSON distinti con eventi non sovrapposti e aggiornando il file JSON descrittore con l'elenco dei nomi dei file JSON.

Consigliato:per ogni file (o shard), imposta il nome del file in modo da indicare il tipo di feed, il timestamp e il numero di shard. I frammenti devono avere dimensioni approssimativamente uguali e vengono elaborati una volta caricati tutti.

Esempio con partizioni

File descriptor - 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"
  ]
}

Shard 0 - event.feeddata.v1_1728306001_001.json

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

Shard 1 - event.feeddata.v1_1728306001_002.json

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

Shard per l'inventario distribuito dal partner

Per i partner può essere difficile consolidare l'inventario distribuito su più sistemi e/o regioni in un unico feed. Lo sharding può essere utilizzato per risolvere i problemi di riconciliazione impostando ogni shard in modo che corrisponda all'insieme di inventari di ciascun sistema distribuito.

Ad esempio, supponiamo che l'inventario di un partner sia suddiviso in due regioni (inventario degli Stati Uniti e dell'UE), che si trovano in due sistemi distinti.

Il partner può suddividere ogni feed in due file (o shard):

Per assicurarti che i feed vengano elaborati correttamente:

  1. Scegli una pianificazione dei caricamenti e configura ogni istanza dell'inventario in modo che rispetti la pianificazione.
  2. Assegna numeri di shard univoci per ogni istanza (ad es. US = N, EU = N + 1). Imposta total_shards sul numero totale di shard.
  3. A ogni ora di caricamento programmata, scegli un generation_timestamp. Imposta tutti i nomi file in modo che abbiano gli stessi valori per questi due campi e elenca tutti i nomi file previsti nel file descrittore.
    • generation_timestamp deve essere attuale o recente (idealmente, il timestamp del database di lettura del partner)
  4. Dopo aver caricato tutti i frammenti, Google li raggruppa utilizzando generation_timestamp e nonce.

Google elaborerà il feed come un unico feed anche se ogni frammento rappresenta una regione diversa dell'inventario del partner e potrebbe essere caricato in un momento diverso della giornata, purché generation_timestamp sia lo stesso in tutti i frammenti.