Google Ads API 항목 및 보고 데이터를 가져오려면 다음 방법 중 하나를 사용하세요.
두 방법의 대략적인 차이점은 다음과 같습니다.
| GoogleAdsService.SearchStream | GoogleAdsService.Search | |
|---|---|---|
| 프로덕션 코드에 적합 | 예 | 예 |
| 서비스 | GoogleAdsService |
GoogleAdsService |
| 시나리오 | 객체 및 보고서 가져오기 | 객체 및 보고서 가져오기 |
| 응답 | GoogleAdsRow 객체의 스트림 |
GoogleAdsRow 객체의 페이지 |
| 대답의 필드 | 쿼리에 지정된 항목만 | 쿼리에 지정된 항목만 |
| 일일 한도 | 액세스 수준에 따른 일일 한도 | 액세스 수준에 따른 일일 한도 |
SearchStream 및 Search 비교
Search는 전체 보고서를 다운로드하기 위해 페이지로 나누어진 요청을 여러 개 보낼 수 있지만 SearchStream는 단일 요청을 보내고 보고서 크기와 관계없이 Google Ads API와의 지속적인 연결을 시작합니다.
SearchStream의 경우 데이터 패킷이 즉시 다운로드되기 시작하며 전체 결과가 데이터 버퍼에 캐시됩니다. 전체 스트림이 완료될 때까지 기다리지 않고 버퍼링된 데이터를 읽기 시작할 수 있습니다.
앱에 따라 Search 응답의 각 개별 페이지를 요청하는 데 필요한 왕복 네트워크 시간을 없애면 SearchStream는 특히 더 큰 보고서의 경우 페이징보다 성능을 향상시킬 수 있습니다.
예
이 예에서는 100,000 행으로 구성된 보고서를 살펴봅니다. 다음 표에서는 두 방법 간의 회계 차이점을 보여줍니다.
| SearchStream | 검색 | |
|---|---|---|
| 페이지 크기 | 해당 없음 | 페이지당 10,000개 행 |
| API 요청 수 | 요청 1개 | 요청 10개 |
| API 응답 수 | 1개의 연속 스트림 | 10개의 응답 |
성능 요인
대부분의 사용 사례에서는 다음과 같은 이유로 Search보다 SearchStream를 사용하는 것이 좋습니다.
단일 페이지 보고서 (10,000개 미만의 행): 두 방법 간에 실적 차이가 크지 않습니다.
여러 페이지 보고서의 경우 일반적으로 여러 왕복이 방지되고 디스크 캐시에서 읽거나 쓰는 것이 덜 중요하므로
SearchStream이 더 빠릅니다.
비율 제한
두 방법의 일일 한도는 개발자 토큰의 표준 한도와 액세스 수준을 따릅니다. 결과가 페이지로 나뉘거나 스트리밍되는지와 관계없이 단일 쿼리 또는 보고서는 하나의 작업으로 계산됩니다.