如要擷取 Google Ads API 實體和報表資料，您可以使用下列其中一種方法：
以下是這兩種方法的概略差異：
| GoogleAdsService.SearchStream | GoogleAdsService.Search | |
|---|---|---|
| 適合實際執行程式碼 | 是 | 是 |
| 服務 | GoogleAdsService |
GoogleAdsService |
| 情境 | 擷取物件和報表 | 擷取物件和報表 |
| 回覆 | GoogleAdsRow 物件的串流 |
GoogleAdsRow 物件頁面 |
| 回應的欄位 | 僅查詢中指定的查詢 | 僅查詢中指定的查詢 |
| 每日上限 | 每日上限 (依存取層級) | 每日上限 (依存取層級) |
SearchStream 與搜尋
雖然 Search 可傳送多個分頁要求以下載整份報表，但 SearchStream 會傳送單一要求，並啟動與 Google Ads API 的永久連線，無論報表大小為何。
如果是 SearchStream，系統會立即開始下載資料封包，並在資料緩衝區中快取整個結果。您的程式碼不必等待整個串流完成，就能開始讀取緩衝的資料。
視應用程式而定，藉由消除要求 Search 回應個別頁面所需的往返網路時間，SearchStream 可以改善分頁效能，尤其是對大型報表而言。
範例
範例說明包含 100,000 列的報表。下表分析這兩種方法之間的會計差異。
| SearchStream | 搜尋 | |
|---|---|---|
| 頁面大小 | 不適用 | 每頁 10,000 列 |
| API 要求數 | 1 項要求 | 10 個要求 |
| API 回應數 | 1 個連續串流 | 10 則回應 |
效能因素
在多數情況下，我們建議使用 SearchStream 而非 Search，原因如下：
單一網頁報表 (少於 10,000 列)：這兩種方法的效能沒有顯著差異。
針對多頁報表：
SearchStream通常速度較快，因為可避免多次往返，且從磁碟快取讀取或寫入資料的重要性。
頻率限制
這兩種方法的每日限制均符合開發人員權杖的標準限制和存取層級。無論結果是否經過分頁或串流，單一查詢或報表都會計為一次作業。