Sử dụng bộ sưu tập để sắp xếp ngăn nắp các trang
Lưu và phân loại nội dung dựa trên lựa chọn ưu tiên của bạn.
Tuỳ thuộc vào khoảng không quảng cáo, bạn có thể cần phải phân đoạn (hoặc chia nguồn cấp dữ liệu thành nhiều tệp).
Trường hợp sử dụng tính năng phân đoạn
Nguồn cấp dữ liệu vượt quá 200 MB cho 1 tệp (sau khi nén gzip).
Ví dụ: Nguồn cấp dữ liệu về tình trạng còn hàng đã tạo có kích thước 1 GB. Bạn nên phân đoạn tệp này thành 5 tệp riêng biệt trở lên (hoặc mảnh).
Khoảng không quảng cáo của đối tác được phân phối trên nhiều hệ thống và/hoặc khu vực, dẫn đến việc khó đối chiếu khoảng không quảng cáo.
Ví dụ: Đối tác có khoảng không quảng cáo ở Hoa Kỳ và Liên minh Châu Âu nằm trong các hệ thống riêng biệt. Nguồn cấp dữ liệu có thể được tạo bằng 2 tệp (hoặc mảnh), 1 cho Hoa Kỳ và 1 cho Liên minh Châu Âu với cùng một nonce và generation_timestamp.
Quy tắc chung
Mỗi mảnh không được vượt quá 200 MB cho 1 tệp (sau khi nén gzip).
Bạn không nên tạo quá 20 phân mảnh cho mỗi nguồn cấp dữ liệu. Nếu bạn có lý do kinh doanh cần nhiều hơn số tiền đó, vui lòng liên hệ với nhóm hỗ trợ để được hướng dẫn thêm.
Bạn phải gửi từng bản ghi (ví dụ: một đối tượng Merchant) trong một phân mảnh, không thể chia các bản ghi đó trên nhiều phân mảnh. Tuy nhiên, bạn không nhất thiết phải gửi các yêu cầu này trong phân đoạn bằng cùng một shard_number cho các nguồn cấp dữ liệu trong tương lai.
Để có hiệu suất tốt hơn, dữ liệu của bạn phải được phân chia đều giữa các phân đoạn để tất cả các tệp được phân đoạn có kích thước tương tự nhau.
Cách phân đoạn nguồn cấp dữ liệu
Đối với mỗi tệp (hoặc mảnh), hãy đặt FeedMetadata thành như sau:
processing_instructionđược đặt thành PROCESS_AS_COMPLETE.
shard_number được đặt thành phân đoạn hiện tại của nguồn cấp dữ liệu
(bắt đầu từ 0 đến total_shards – 1 mà không có giá trị gián đoạn)
total_shards được đặt thành tổng số mảnh cho nguồn cấp dữ liệu (bắt đầu từ 1).
nonce được đặt thành một giá trị nhận dạng duy nhất giống nhau trên tất cả các mảnh của cùng một nguồn cấp dữ liệu nhưng khác với giá trị của các nguồn cấp dữ liệu khác. nonce phải là số nguyên dương (uint64).
generation_timestamp là dấu thời gian ở định dạng Unix và EPOCH. Giá trị này phải giống nhau trên tất cả các mảnh của nguồn cấp dữ liệu.
Đề xuất: Đối với mỗi tệp (hoặc phân đoạn), hãy đặt tên tệp để cho biết loại nguồn cấp dữ liệu, dấu thời gian, số phân đoạn và tổng số phân đoạn. Các mảnh phải có kích thước gần bằng nhau và được xử lý sau khi tất cả các mảnh được tải lên.
Sử dụng tính năng phân đoạn cho khoảng không quảng cáo do đối tác phân phối
Đối tác có thể gặp khó khăn khi hợp nhất khoảng không quảng cáo được phân phối trên nhiều hệ thống và/hoặc khu vực vào một nguồn cấp dữ liệu. Bạn có thể sử dụng tính năng phân đoạn để giải quyết các thách thức đối với việc điều chỉnh bằng cách thiết lập từng phân đoạn sao cho khớp với từng nhóm khoảng không quảng cáo của hệ thống phân phối.
Ví dụ: giả sử kho hàng của một đối tác được chia thành 2 khu vực (kho hàng ở Hoa Kỳ và kho hàng ở Liên minh Châu Âu), nằm trong 2 hệ thống riêng biệt.
Đối tác có thể chia mỗi nguồn cấp dữ liệu thành 2 tệp (hoặc phân đoạn):
Nguồn cấp dữ liệu người bán: 1 phân mảnh cho Hoa Kỳ, 1 phân mảnh cho Liên minh Châu Âu
Nguồn cấp dữ liệu dịch vụ: 1 phân mảnh cho Hoa Kỳ, 1 phân mảnh cho Liên minh Châu Âu
Nguồn cấp dữ liệu về tình trạng còn hàng: 1 phân mảnh cho Hoa Kỳ, 1 phân mảnh cho Liên minh Châu Âu
Hãy làm theo các bước bên dưới để đảm bảo nguồn cấp dữ liệu được xử lý đúng cách:
Quyết định lịch tải lên và định cấu hình từng phiên bản khoảng không quảng cáo để
tuân theo lịch đó.
Chỉ định số phân đoạn duy nhất cho mỗi thực thể (ví dụ: Hoa Kỳ = N, Liên minh Châu Âu = N + 1).
Đặt total_shards thành tổng số mảnh.
Tại mỗi thời điểm tải lên theo lịch, hãy quyết định một generation_timestamp và nonce. Trong FeedMetadata, hãy đặt tất cả các thực thể để giữ cùng một giá trị cho hai trường này.
generation_timestamp phải là hiện tại hoặc gần đây (tốt nhất là dấu thời gian đọc trong cơ sở dữ liệu của đối tác)
Sau khi tất cả các mảnh được tải lên, Google sẽ nhóm các mảnh thông qua generation_timestamp và nonce.
Google sẽ xử lý nguồn cấp dữ liệu dưới dạng một nguồn cấp dữ liệu mặc dù mỗi phân đoạn đại diện cho một khu vực khác nhau trong khoảng không quảng cáo của đối tác và có thể được tải lên vào một thời điểm khác nhau trong ngày, miễn là generation_timestamp giống nhau trên tất cả các phân đoạn.
Ví dụ về nguồn cấp dữ liệu Tình trạng còn hàng được phân đoạn theo khu vực
[null,null,["Cập nhật lần gần đây nhất: 2025-07-26 UTC."],[[["\u003cp\u003eSharding, or splitting feeds into multiple files, is recommended when a single feed file exceeds 200 MB after gzip compression or when inventory is distributed across different systems.\u003c/p\u003e\n"],["\u003cp\u003eEach shard should be under 200 MB after gzip compression, with a recommended maximum of 20 shards per feed.\u003c/p\u003e\n"],["\u003cp\u003eAll shards for a single feed must use the same \u003ccode\u003enonce\u003c/code\u003e and \u003ccode\u003egeneration_timestamp\u003c/code\u003e in their metadata for proper processing.\u003c/p\u003e\n"],["\u003cp\u003eWhen sharding, individual records must be kept within a single shard and cannot be split across multiple shards.\u003c/p\u003e\n"],["\u003cp\u003eFor distributed inventory, sharding can be used to represent different regions or systems by assigning unique shard numbers while maintaining consistent \u003ccode\u003enonce\u003c/code\u003e and \u003ccode\u003egeneration_timestamp\u003c/code\u003e.\u003c/p\u003e\n"]]],["Sharding divides large or geographically diverse feeds into multiple files. Use it when a feed exceeds 200MB after compression or when inventory is in separate systems/regions. Each shard must be under 200MB, with no more than 20 shards per feed. Assign each shard a unique `shard_number` and a common `nonce` and `generation_timestamp`. Shards are processed after the last file is uploaded. Ensure even data distribution across shards for performance, and keep individual records within a single shard.\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/local-services/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/local-services/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```"]]
