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.
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 is a method of splitting large data feeds into smaller, more manageable files for efficient processing, particularly when a feed exceeds 200MB after gzip compression or when inventory is distributed across multiple systems.\u003c/p\u003e\n"],["\u003cp\u003eEach shard must not exceed 200MB after gzip compression, and the total number of shards is ideally limited to 20 or less.\u003c/p\u003e\n"],["\u003cp\u003eShards for the same feed must share a unique identifier (nonce) and timestamp (generation_timestamp), ensuring they are processed as a single unit.\u003c/p\u003e\n"],["\u003cp\u003eIndividual records must be contained within a single shard, but they can be moved to different shards in subsequent feed updates for better data distribution.\u003c/p\u003e\n"],["\u003cp\u003eFor partners with geographically distributed inventory, sharding allows each system or region's inventory to be represented in separate shards while still being processed as a cohesive dataset using a shared nonce and timestamp.\u003c/p\u003e\n"]]],["Sharding, breaking feeds into multiple files, is needed if a feed exceeds 200MB post-compression or if inventory is distributed across systems/regions. Each shard must be under 200MB, with no more than 20 shards per feed. Set `processing_instruction` to `PROCESS_AS_COMPLETE`. Each file needs a `shard_number`, `total_shards`, matching `nonce`, and `generation_timestamp`. Distribute data evenly among shards, upload all shards, and they will be processed as a whole. Unique sharding values can be assigned to reconcile distributed inventory.\n"],null,["# Shard feed files (legacy)\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/healthcare/guides/tutorials/tutorial-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/legacy/reference/starter-integration/feed-error-codes).\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.\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```"]]
