Restez organisé à l'aide des collections
Enregistrez et classez les contenus selon vos préférences.
Selon votre inventaire, le fractionnement (ou la division des flux en plusieurs fichiers) peut être nécessaire.
Quand utiliser le sharding ?
Le flux dépasse 200 Mo pour un fichier (après compression gzip).
Exemple:Le flux de disponibilité généré est de 1 Go. Il doit être divisé en cinq fichiers (ou fragments) ou plus.
L'inventaire des partenaires est réparti entre des systèmes et/ou des régions, ce qui rend la réconciliation de l'inventaire difficile.
Exemple:Le partenaire dispose d'un inventaire aux États-Unis et dans l'Union européenne, qui se trouve dans des systèmes distincts. Le flux peut être généré avec deux fichiers (ou fragments), un pour les États-Unis et un pour l'Union européenne, avec les mêmes nonce et generation_timestamp.
Règles générales
Chaque segment ne peut pas dépasser 200 Mo pour un fichier (après compression gzip).
Nous vous recommandons de ne pas utiliser plus de 20 segments par flux. Si vous avez une justification commerciale qui nécessite un montant supérieur, veuillez contacter l'assistance pour obtenir des instructions.
Les enregistrements individuels (un objet Merchant, par exemple) doivent être envoyés dans un même segment. Ils ne peuvent pas être répartis sur plusieurs segments. Toutefois, ils n'ont pas besoin d'être envoyés dans le segment avec le même shard_number pour les futurs flux.
Pour de meilleures performances, répartissez les données de manière égale entre les segments, afin que la taille de tous les fichiers segmentés soit la même.
Segmenter des flux
Pour chaque fichier (ou fragment), définissez FeedMetadata sur les valeurs suivantes:
processing_instruction défini sur PROCESS_AS_COMPLETE.
shard_number défini sur le segment actuel du flux (à partir de 0 jusqu'à total_shards - 1 sans discontinuités)
total_shards défini sur le nombre total de segments pour le flux (à partir de 1).
nonce défini sur un identifiant unique qui est identique pour tous les fragments du même flux, mais différent de la valeur des autres flux. nonce doit être un entier positif (uint64).
generation_timestamp est l'horodatage au format Unix et EPOCH. Cette valeur doit être identique pour tous les segments du flux.
Recommandation:Pour chaque fichier (ou segment), définissez le nom de fichier pour indiquer le type de flux, le code temporel, le numéro de segment et le nombre total de segments. Les fragments doivent être à peu près de la même taille et sont traités une fois tous les fragments importés.
Utiliser la segmentation pour l'inventaire distribué par les partenaires
Il peut être difficile pour les partenaires de consolider l'inventaire distribué sur plusieurs systèmes et/ou régions dans un seul flux. Le sharding peut être utilisé pour résoudre les problèmes de réconciliation en définissant chaque fragment pour qu'il corresponde à l'ensemble d'inventaire de chaque système distribué.
Par exemple, imaginons que l'inventaire d'un partenaire soit divisé en deux régions (inventaire des États-Unis et de l'UE), qui se trouvent dans deux systèmes distincts.
Le partenaire peut diviser chaque flux en deux fichiers (ou fragments):
Flux marchands: 1 segment pour les États-Unis, 1 segment pour l'UE
Flux services: 1 segment pour les États-Unis, 1 segment pour l'UE
Flux disponibilité: 1 segment pour les États-Unis, 1 segment pour l'Union européenne
Suivez les étapes ci-dessous pour vous assurer que les flux sont correctement traités:
Définissez un calendrier d'importation et configurez chaque instance d'inventaire pour qu'elle suive ce calendrier.
Attribuez des numéros de segment uniques à chaque instance (par exemple, États-Unis = N, Europe = N + 1).
Définissez total_shards sur le nombre total de segments.
À chaque heure d'importation planifiée, choisissez un generation_timestamp et un nonce. Dans FeedMetadata, définissez toutes les instances pour qu'elles contiennent les mêmes valeurs pour ces deux champs.
generation_timestamp doit être actuel ou récent (idéalement, l'horodatage de la base de données de lecture du partenaire)
Une fois tous les fragments importés, Google les regroupe via generation_timestamp et nonce.
Google traitera le flux comme un seul flux, même si chaque segment représente une région différente de l'inventaire du partenaire et qu'il peut être importé à une heure différente de la journée, à condition que le generation_timestamp soit le même pour tous les segments.
Exemple de flux de disponibilité segmenté par région
Sauf indication contraire, le contenu de cette page est régi par une licence Creative Commons Attribution 4.0, et les échantillons de code sont régis par une licence Apache 2.0. Pour en savoir plus, consultez les Règles du site Google Developers. Java est une marque déposée d'Oracle et/ou de ses sociétés affiliées.
Dernière mise à jour le 2025/07/26 (UTC).
[null,null,["Dernière mise à jour le 2025/07/26 (UTC)."],[[["\u003cp\u003eSharding, or splitting feeds into multiple files, is necessary when a single feed file exceeds 200 MB after gzip compression or when inventory is distributed across various systems.\u003c/p\u003e\n"],["\u003cp\u003eEach shard must be under 200 MB after gzip compression, with a recommended maximum of 20 shards per feed, and individual records should be contained within a single shard.\u003c/p\u003e\n"],["\u003cp\u003eSharded feeds utilize \u003ccode\u003eFeedMetadata\u003c/code\u003e with \u003ccode\u003eprocessing_instruction\u003c/code\u003e, \u003ccode\u003eshard_number\u003c/code\u003e, \u003ccode\u003etotal_shards\u003c/code\u003e, a unique \u003ccode\u003enonce\u003c/code\u003e, and a consistent \u003ccode\u003egeneration_timestamp\u003c/code\u003e across all shards.\u003c/p\u003e\n"],["\u003cp\u003ePartners with distributed inventory can utilize sharding to reconcile data by assigning shards to specific systems or regions, ensuring consistent \u003ccode\u003enonce\u003c/code\u003e and \u003ccode\u003egeneration_timestamp\u003c/code\u003e values for cohesive processing.\u003c/p\u003e\n"]]],["Sharding divides feeds into multiple files when a single file exceeds 200 MB (after gzip compression) or inventory is distributed across systems/regions. Each shard's `FeedMetadata` requires `processing_instruction`, `shard_number`, `total_shards`, a unique `nonce` shared across all shards of the same feed, and a common `generation_timestamp`. Individual records must remain in a single shard. It is recommended to keep shard amounts at 20 max, and each shard should be roughly equal in size. Google starts processing after all shards are uploaded.\n"],null,["# Shard feed files\n\nDepending on your inventory, sharding (or breaking up feeds into multiple\nfiles) may be necessary.\n| **Note:** Sharding might only be applicable to some of the feeds you submit and is dependent on the type of inventory submitted. Please reach out to your Google contact if you are unsure of the best approach.\n\nWhen to use sharding\n--------------------\n\n- Feed exceeds 200 MB for 1 file (after gzip compression).\n\n - **Example:** Generated availability feed is 1 GB. This should be sharded to 5+ separate files (or shards).\n- Partner inventory is distributed across systems and/or regions\n resulting in difficulty reconciling the inventory.\n\n - **Example:** Partner has US and EU inventory that live in separate systems. The feed may be generated with 2 files (or shards), 1 for US, and 1 for EU with the same `nonce` and `generation_timestamp`.\n\n| **Note:** Before using sharding, make sure you are [compressing your feed uploads with gzip](/actions-center/verticals/reservations/e2e/reference/tutorials/compression). Using gzip can reduce feed size by 10x or more, and may allow you to skip or defer sharding your feed.\n\nGeneral rules\n-------------\n\n- Each shard cannot exceed 200 MB for 1 file (after gzip compression).\n- We recommend no more than 20 shards per feed. If you have a business justification that requires more than that amount, please contact support for further instruction.\n- Individual records (one `Merchant` object for example) must be sent in one shard, they cannot be split across multiple shards. However, they don't have to be sent in the shard with the same `shard_number` for future feeds.\n- For better performance, your data should be split evenly among the shards so that all sharded files are similar in size.\n\n| **Note:** Google processes feed files as soon as they're uploaded to the SFTP server. If the feed is sharded into multiple files, the process begins after you upload the last file. If your feed contains errors, you receive an email with the [feed error codes](/actions-center/verticals/reservations/e2e/reference/feeds/feed-errors).\n\nHow to shard feeds\n------------------\n\nFor each file (or shard), set the `FeedMetadata` to the\nfollowing:\n\n- `processing_instruction`set to `PROCESS_AS_COMPLETE`.\n- `shard_number` set to to the current shard of the feed (starting from 0 to `total_shards` - 1 without discontinuities)\n- `total_shards` set to the total number of shards for the feed (starting from 1).\n- `nonce` set to a unique identifier that is **the same** across all shards of **the same** feed but different from the value of other feeds. `nonce` must be a positive int (`uint64`).\n- `generation_timestamp` is the timestamp in unix and EPOCH format. This should be **the same** across all shards of the feed.\n\n*Recommended:* For each file (or shard), set the filename to indicate\nthe feed type, the timestamp, the shard number, and the total number of\nshards. Shards should be roughly equal in size and are processed once all\nshards are uploaded.\n\n- `Example:` \"availability_feed_1574117613_001_of_002.json.gz\"\n\n**Sharded Availability feed example** \n\n### Shard 0\n\n```scdoc\n{\n \"metadata\": {\n \"processing_instruction\": \"PROCESS_AS_COMPLETE\",\n \"shard_number\": 0,\n \"total_shards\": 3,\n \"nonce\": 111111,\n \"generation_timestamp\": 1524606581\n },\n \"service_availability\": [\n {\n \"availability\": [\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1577275200,\n \"merchant_id\": \"merchant1\",\n \"confirmation_mode\": \"CONFIRMATION_MODE_SYNCHRONOUS\"\n }\n ]\n }\n ]\n}\n```\n\n### Shard 1\n\n```scdoc\n{\n \"metadata\": {\n \"processing_instruction\": \"PROCESS_AS_COMPLETE\",\n \"shard_number\": 1,\n \"total_shards\": 3,\n \"nonce\": 111111,\n \"generation_timestamp\": 1524606581\n },\n \"service_availability\": [\n {\n \"availability\": [\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1577620800,\n \"merchant_id\": \"merchant2\",\n \"confirmation_mode\": \"CONFIRMATION_MODE_SYNCHRONOUS\"\n }\n ]\n }\n ]\n}\n```\n\n### Shard 2\n\n```scdoc\n{\n \"metadata\": {\n \"processing_instruction\": \"PROCESS_AS_COMPLETE\",\n \"shard_number\": 2,\n \"total_shards\": 3,\n \"nonce\": 111111,\n \"generation_timestamp\": 1524606581\n },\n \"service_availability\": [\n {\n \"availability\": [\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1576670400,\n \"merchant_id\": \"merchant3\",\n \"confirmation_mode\": \"CONFIRMATION_MODE_SYNCHRONOUS\"\n }\n ]\n }\n ]\n}\n```\n\nUsing sharding for partner distributed inventory\n------------------------------------------------\n\nIt can be challenging for partners to consolidate inventory distributed\nacross multiple systems and or regions into a single feed. Sharding can be\nused to resolve reconciliation challenges by setting each shard to match each\ndistributed system's inventory set.\n\nFor example, say a partner's inventory is separated into 2 regions (US and EU\ninventory), which live in 2 separate systems.\n\nThe partner can break each feed into 2 files (or shards):\n\n- Merchants feed: 1 shard for US, 1 shard for EU\n- Services feed: 1 shard for US, 1 shard for EU\n- Availability feed: 1 shard for US, 1 shard for EU\n\nFollow the steps below to ensure the feeds are properly processed:\n\n1. Decide on an upload schedule, and configure each instance of inventory to follow the schedule.\n2. Assign unique shard numbers for each instance (e.g. US = N, EU = N + 1). Set `total_shards` to the total number of shards.\n3. At each scheduled upload time, decide on a `generation_timestamp` and `nonce`. In the `FeedMetadata`, set all instances to hold the same values for these two fields.\n - `generation_timestamp` should be current or recent past (ideally, the partner's read-at database timestamp)\n4. After all shards are uploaded, Google groups the shards via `generation_timestamp` and `nonce`.\n\n| **Note:** Feeds/shards arriving separately at different times is supported, but coordinated schedules is best. Feed processing occurs only when all shards in a feed set are uploaded.\n\nGoogle will process the feed as one even though each shard represents a\ndifferent region of the partner's inventory and could be uploaded at a\ndifferent time of the day as long as the `generation_timestamp`\nis the same across all shards.\n\n**Sharded Availability feed example by region** \n\n### Shard 0 - US Inventory\n\n```scdoc\n{\n \"metadata\": {\n \"processing_instruction\": \"PROCESS_AS_COMPLETE\",\n \"shard_number\": 0,\n \"total_shards\": 2,\n \"nonce\": 111111,\n \"generation_timestamp\": 1524606581\n },\n \"service_availability\": [\n {\n \"availability\": [\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1577275200,\n \"merchant_id\": \"US_merchant_1\",\n \"confirmation_mode\": \"CONFIRMATION_MODE_SYNCHRONOUS\"\n }\n ]\n }\n ]\n}\n```\n\n### Shard 1 - EU Inventory\n\n```scdoc\n{\n \"metadata\": {\n \"processing_instruction\": \"PROCESS_AS_COMPLETE\",\n \"shard_number\": 1,\n \"total_shards\": 2,\n \"nonce\": 111111,\n \"generation_timestamp\": 1524606581\n },\n \"service_availability\": [\n {\n \"availability\": [\n {\n \"spots_total\": 1,\n \"spots_open\": 1,\n \"duration_sec\": 3600,\n \"service_id\": \"1000\",\n \"start_sec\": 1577620800,\n \"merchant_id\": \"EU_merchant_1\",\n \"confirmation_mode\": \"CONFIRMATION_MODE_SYNCHRONOUS\"\n }\n ]\n }\n ]\n}\n```"]]
