File feed shard

Bergantung pada inventaris Anda, sharding (atau membagi feed menjadi beberapa file) mungkin diperlukan.

Kapan harus menggunakan sharding

  • Feed melebihi 200 MB untuk 1 file (setelah kompresi gzip).

    • Contoh: Feed ketersediaan yang dihasilkan adalah 1 GB. File ini harus di-shard ke 5 file terpisah (atau shard).

  • Inventaris partner didistribusikan di seluruh sistem dan/atau region sehingga menyulitkan rekonsiliasi inventaris.

    • Contoh: Partner memiliki inventaris AS dan Uni Eropa yang berada di sistem terpisah. Feed dapat dibuat dengan 2 file (atau shard), 1 untuk AS, dan 1 untuk Uni Eropa dengan nonce dan generation_timestamp yang sama.

Peraturan umum

  • Setiap shard tidak boleh melebihi 200 MB untuk 1 file (setelah kompresi gzip).
  • Sebaiknya jangan gunakan lebih dari 20 shard per feed. Jika Anda memiliki justifikasi bisnis yang memerlukan lebih dari jumlah tersebut, hubungi dukungan untuk mendapatkan petunjuk lebih lanjut.
  • Setiap kumpulan data (misalnya, satu objek Merchant) harus dikirim dalam satu shard, dan tidak dapat dibagi di beberapa shard. Namun, iklan ini tidak harus dikirim dalam shard dengan shard_number yang sama untuk feed mendatang.
  • Untuk mendapatkan performa yang lebih baik, data Anda harus dibagi secara merata di antara shard sehingga semua file yang di-sharding memiliki ukuran yang serupa.

Cara melakukan sharding feed

Anda dapat membuat shard feed peristiwa dengan membagi satu JSON menjadi file JSON terpisah dengan peristiwa yang tidak tumpang-tindih dan memperbarui JSON deskripsi file dengan daftar nama file JSON.

Direkomendasikan: Untuk setiap file (atau shard), tetapkan nama file untuk menunjukkan jenis feed, stempel waktu, dan nomor shard. Ukuran shard harus kurang lebih sama dan diproses setelah semua shard diupload.

Contoh shard

Deskripsi file - 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 untuk inventaris yang didistribusikan partner

Partner mungkin kesulitan untuk menggabungkan inventaris yang didistribusikan di beberapa sistem dan atau wilayah ke dalam satu feed. Sharding dapat digunakan untuk menyelesaikan tantangan rekonsiliasi dengan menetapkan setiap shard agar cocok dengan setiap set inventaris sistem terdistribusi.

Misalnya, inventaris partner dipisahkan menjadi 2 wilayah (inventaris Amerika Serikat dan Uni Eropa), yang berada di 2 sistem terpisah.

Partner dapat membagi setiap feed menjadi 2 file (atau shard):

Gunakan langkah-langkah berikut untuk memastikan feed diproses dengan benar:

  1. Tentukan jadwal upload, dan konfigurasikan setiap instance inventaris untuk mengikuti jadwal.
  2. Tetapkan nomor shard unik untuk setiap instance (misalnya, AS = N, Uni Eropa = N + 1). Tetapkan total_shards ke jumlah total shard.
  3. Pada setiap waktu upload terjadwal, tentukan generation_timestamp. Tetapkan semua nama file untuk menyimpan nilai yang sama untuk kedua kolom ini dan cantumkan semua nama file yang diharapkan dalam file deskripsi.
    • generation_timestamp harus berupa saat ini atau masa lalu terbaru (idealnya, stempel waktu database read-at partner)
  4. Setelah semua shard diupload, Google mengelompokkan shard menggunakan generation_timestamp dan nonce.

Google akan memproses feed sebagai satu meskipun setiap shard mewakili wilayah inventaris partner yang berbeda dan dapat diupload pada waktu yang berbeda selama generation_timestamp sama di semua shard.