تنظيم صفحاتك في مجموعات
يمكنك حفظ المحتوى وتصنيفه حسب إعداداتك المفضّلة.
استنادًا إلى مستودعك، قد يكون من الضروري تقسيم الخلاصات إلى عدة
ملفات.
حالات استخدام التقسيم
حجم الخلاصة أكبر من 200 ميغابايت لملف واحد (بعد ضغط gzip)
مثال: حجم خلاصة مدى التوفّر التي تم إنشاؤها هو 1 غيغابايت. يجب أن تتم
تقسيمها إلى 5 ملفات (أو أجزاء) منفصلة أو أكثر.
يتم توزيع مستودع الشركاء على مستوى الأنظمة و/أو المناطق، مما يؤدي إلى صعوبة تسوية المستودع.
مثال: لدى الشريك مستودع إعلاني في الولايات المتحدة والاتحاد الأوروبي على
نظامَين منفصلَين. يمكن إنشاء الخلاصة باستخدام ملفين (أو شريحة)، أحدهما للولايات المتحدة
والآخر للاتحاد الأوروبي باستخدام nonce و
generation_timestamp نفسهما.
قواعد عامة
لا يمكن أن يتجاوز حجم كل جزء 200 ميغابايت لملف واحد (بعد ضغط gzip).
ننصحك بعدم استخدام أكثر من 20 شريحة لكل خلاصة. إذا كان لديك مبرر تجاري يتطلب
مبلغًا أكبر، يُرجى التواصل مع فريق الدعم للحصول على مزيد من التعليمات.
يجب إرسال السجلات الفردية (عنصر Merchant واحد مثلاً) في شريحة واحدة،
ولا يمكن تقسيمها على شرائح متعددة. ومع ذلك، ليس من الضروري إرسالها في الشريحة
باستخدام shard_number نفسه للخلاصات المستقبلية.
للحصول على أداء أفضل، يجب تقسيم بياناتك بالتساوي بين
الأجزاء حتى تكون جميع الملفات المجزّأة متشابهة في الحجم.
كيفية تقسيم الخلاصات
بالنسبة إلى كل ملف (أو جزء)، اضبط FeedMetadata على القيمة التالية:
تم ضبط processing_instruction على
PROCESS_AS_COMPLETE.
shard_number تم ضبطه على الشريحة الحالية للخلاصة
(بدءًا من 0 إلى total_shards - 1 بدون انقطاع)
total_shards تم ضبطه على إجمالي عدد الأجزاء للغذاء (بدءًا من 1).
nonce تم ضبطه على معرّف فريد مماثل
في جميع أقسام الخلاصة نفسها ولكنّه يختلف عن قيمة
الخلاصات الأخرى. يجب أن يكون nonce عددًا صحيحًا موجبًا (uint64).
generation_timestamp هو الطابع الزمني بتنسيق يونكس وEPOCH. يجب أن يكون هذا متوافقًا في جميع أقسام الخلاصة.
إجراء مقترَح: لكل ملف (أو جزء)، اضبط اسم الملف للإشارة إلى نوع الخلاصة والطابع الزمني ورقم الجزء وإجمالي عدد الأجزاء. يجب أن تكون الأجزاء متساوية تقريبًا في الحجم، ويتمّت معالجتها بعد تحميل كل
الأجزاء.
استخدام التقسيم للمستودع الإعلاني الموزّع من الشركاء
قد يكون من الصعب على الشركاء دمج المستودع الإعلاني الموزَّع
على أنظمة و/أو مناطق متعدّدة في خلاصة واحدة. يمكن استخدام ميزة "تقسيم البيانات"
لحلّ مشاكل المطابقة من خلال ضبط كل جزء لتطابق كل مجموعة مستودع
للنظام الموزّع.
على سبيل المثال، لنفترض أنّ مستودع الشريك مُقسَّم إلى منطقتَين (مستودع
الولايات المتحدة والاتحاد الأوروبي)، وكلاهما مُدرَج في نظامَين منفصلَين.
يمكن للشريك تقسيم كل خلاصة إلى ملفين (أو جزءَين):
خلاصة التجّار: شريحة واحدة للولايات المتحدة وشريحة واحدة للاتحاد الأوروبي
خلاصة الخدمات: شريحة واحدة للولايات المتحدة وشريحة واحدة للاتحاد الأوروبي
خلاصة مدى التوفّر: شريحة واحدة للولايات المتحدة وشريحة واحدة للاتحاد الأوروبي
اتّبِع الخطوات التالية لضمان معالجة الخلاصات بشكلٍ صحيح:
حدِّد جدولاً زمنيًا لتحميل المحتوى، واضبط كل مثيل من المستودع لكي يليد جدولك الزمني.
يمكنك تخصيص أرقام شرائح فريدة لكل مثيل (مثل الولايات المتحدة = N، والاتحاد الأوروبي = N + 1).
اضبط total_shards على إجمالي عدد الأقسام.
في كل وقت محدّد لتحميل الفيديوهات، حدِّد
generation_timestamp وnonce. في
FeedMetadata، اضبط جميع النُسخ على احتواء القيم نفسها ل
هذين الحقلين.
يجب أن يكون تاريخ generation_timestamp حاليًا أو مؤخرًا
(من الأفضل استخدام الطابع الزمني لقراءة الشريك في قاعدة البيانات).
بعد تحميل جميع الأجزاء، تُجمِّع Google الأجزاء من خلال
generation_timestamp وnonce.
ستعالج Google الخلاصة كوحدة واحدة على الرغم من أنّ كل جزء يمثّل
منطقة مختلفة من مستودع الشريك ويمكن تحميله في
وقت مختلف من اليوم ما دام generation_timestamp
هو نفسه في جميع الأجزاء.
تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)
[null,null,["تاريخ التعديل الأخير: 2025-07-26 (حسب التوقيت العالمي المتفَّق عليه)"],[[["\u003cp\u003eSharding, or splitting feeds into multiple files, is recommended when a feed exceeds 200MB after gzip compression or when inventory is distributed across various systems/regions.\u003c/p\u003e\n"],["\u003cp\u003eEach shard should not exceed 200MB after gzip compression, with a recommended maximum of 20 shards per feed.\u003c/p\u003e\n"],["\u003cp\u003eShards are processed as a complete feed once all shards are uploaded, and should contain the same \u003ccode\u003enonce\u003c/code\u003e and \u003ccode\u003egeneration_timestamp\u003c/code\u003e in their metadata.\u003c/p\u003e\n"],["\u003cp\u003eIndividual records must be sent in one shard, but can be moved to different shards in future feeds for load balancing.\u003c/p\u003e\n"],["\u003cp\u003ePartners with distributed inventory can utilize sharding to represent each system's inventory set within individual shards for easier reconciliation.\u003c/p\u003e\n"]]],["Sharding divides large feeds into multiple files when a single feed exceeds 200MB (after gzip compression) or when inventory is distributed across different systems/regions. Each shard must be under 200MB, and it is recommended to keep the total number of shards to 20 or fewer. Shards should be evenly sized and include `shard_number`, `total_shards`, a common `nonce`, and `generation_timestamp`. Sharding can also help with inventory reconciliation and data can be split by region or system. All shards must be uploaded to process the feed.\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/bl/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/bl/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```"]]
