할당량 및 한도
이 문서에서는 BigQuery에 적용되는 할당량과 한도에 대해 설명합니다.
할당량은 하드웨어, 소프트웨어, 네트워크 구성요소를 비롯해 Cloud 프로젝트가 사용할 수 있는 특정 공유 Google Cloud 리소스의 양을 제한합니다.
할당량은 다음을 수행하는 시스템의 일부입니다.
- Google Cloud 제품 및 서비스 사용 또는 소비량을 모니터링합니다.
- 공정성 보장 및 사용량 급증 방지 등 여러 이유로 리소스 소비를 제한합니다.
- 사전 정의된 제한사항을 자동으로 적용하는 구성을 유지합니다.
- 할당량을 변경하거나 변경을 요청할 수 있는 수단을 제공합니다.
할당량이 초과되면 대부분의 경우 시스템에서 관련 Google 리소스에 대한 액세스를 즉시 차단하고 수행하려는 작업이 실패합니다. 대부분의 경우 할당량은 각 Cloud 프로젝트에 적용되며 해당 Cloud 프로젝트를 사용하는 모든 애플리케이션과 IP 주소 전반에 공유됩니다.
BigQuery 리소스에도 한도가 있습니다. 이 한도는 할당량 시스템과 관련이 없습니다. 별도로 명시되지 않는 한 한도를 변경할 수 없습니다.
기본적으로 BigQuery 할당량 및 한도는 프로젝트별로 적용됩니다. 다른 단위로 적용되는 할당량과 한도는 테이블당 최대 열 수 또는 사용자당 최대 동시 API 요청 수 등으로 표시됩니다. 구체적인 정책은 리소스 가용성, 사용자 프로필, 서비스 사용 기록, 기타 요인에 따라 다르며 사전 통보 없이 변경될 수 있습니다.
할당량 보충
일일 할당량은 비율을 제한하는 동작을 유도하기 위해 온종일 정기적으로 보충됩니다. 할당량이 소진되었을 때 장시간 중단되지 않도록 간헐적인 보충도 이루어집니다. 할당량은 하루에 한 번 전체적으로 보충되기보다는 대개 몇 분 단위로 제공됩니다.
할당량 증가 요청
대부분의 할당량은 Google Cloud Console을 사용해 늘리거나 줄입니다. 자세한 내용은 더 높은 할당량 요청을 참조하세요.
Google Cloud 콘솔의 할당량 상향 요청 절차에 대한 단계별 안내를 보려면 둘러보기를 클릭하세요.
사용 할당량 상한
기본 할당량보다 적은 할당량을 지정하여 특정 리소스의 사용량을 제한하는 방법은 사용량 상한 설정을 참조하세요.
필수 권한
Google Cloud 콘솔에서 BigQuery 할당량을 보고 업데이트하려면 Google Cloud 할당량과 동일한 권한이 필요합니다. 자세한 내용은 Google Cloud 할당량 권한을 참조하세요.
문제해결
할당량 및 한도 관련 오류 문제 해결에 대한 자세한 내용은 BigQuery 할당량 오류 문제 해결을 참조하세요.
작업
할당량과 한도는 BigQuery에서 사용자를 대신하여 Google Cloud Console, bq
명령줄 도구를 사용하거나 REST API나 클라이언트 라이브러리를 사용하여 프로그래매틱 방식으로 실행하는 작업에 적용됩니다.
쿼리 작업
대화형 쿼리, 예약된 쿼리를 실행하여 자동으로 생성되는 쿼리 작업과 jobs.query
및 쿼리 유형 jobs.insert
API 메서드를 사용하여 제출된 작업에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
일일 쿼리 사용량 | 무제한 | 프로젝트에서 쿼리가 처리할 수 있는 바이트 수에는 제한이 없습니다. Google Cloud 콘솔에서 할당량 보기 |
사용자당 일일 쿼리 사용량 | 무제한 | 사용자 쿼리가 매일 처리할 수 있는 바이트 수에는 제한이 없습니다. Google Cloud 콘솔에서 할당량 보기 |
Cloud SQL 통합 쿼리의 리전 간 일일 바이트 | 1TB | BigQuery 쿼리 처리 위치와 Cloud SQL 인스턴스 위치가 다르면 쿼리가 리전 간 쿼리입니다. 프로젝트에서 리전 간 쿼리를 하루 최대 1TB까지 실행할 수 있습니다. Cloud SQL 통합 쿼리를 참조하세요. Google Cloud 콘솔에서 할당량 보기 |
클라우드 간 일일 전송 바이트 수 | 1TB |
Amazon S3 버킷 또는 Azure Blob Storage에서 하루에 최대 1TB의 데이터를 전송할 수 있습니다. 자세한 내용은 Amazon S3에서 클라우드 간 전송과 Azure를 참조하세요.
Google Cloud 콘솔에서 할당량 보기 |
대화형 쿼리, 예약된 쿼리를 실행하여 자동으로 생성되는 쿼리 작업과 jobs.query
및 쿼리 유형 jobs.insert
API 메서드를 사용하여 제출된 작업에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 동시 대화형 쿼리 수 | 쿼리 100회 |
프로젝트에서 최대 100개의 동시 대화형 쿼리를 실행할 수 있습니다.
쿼리 캐시에서 반환된 결과가 있는 쿼리는 BigQuery에서 캐시 적중이라고 판단할 때까지 이 한도에 포함됩니다. 테스트 실행 쿼리는 이 한도에 반영되지 않습니다. --dry_run 플래그를 사용하여 테스트 실행 쿼리를 지정할 수 있습니다. 이 한도를 초과하지 않는 전략에 대한 자세한 내용은 할당량 오류 문제 해결을 참조하세요.
이러한 오류를 완화하는 한 가지 방법은 쿼리 큐(미리보기)를 사용 설정하는 것입니다. 쿼리 큐는 동적 동시 실행 한도를 제공하며, 실행 중인 쿼리 외에도 최대 1,000개의 대화형 쿼리를 큐에 추가합니다.
|
큐에 추가된 대화형 쿼리의 최대 개수 | 쿼리 1,000회 | 쿼리 큐(미리보기)가 사용 설정되었으면 프로젝트가 최대 1,000개까지 대화형 쿼리를 큐에 추가할 수 있습니다. 이 한도를 초과하는 추가 대화형 쿼리는 할당량 오류를 반환합니다. |
최대 동시 일괄 쿼리 수 | 쿼리 10개 | 프로젝트에서 동시 일괄 쿼리를 최대 10개까지 실행할 수 있습니다. |
큐에 추가된 일괄 쿼리의 최대 개수 | 20,000개 쿼리 | 프로젝트는 최대 20,000개까지 일괄 쿼리를 큐에 넣을 수 있습니다. 이 한도를 초과하는 추가 일괄 쿼리는 할당량 오류를 반환합니다. |
Cloud Bigtable 외부 데이터 소스를 대상으로 한 동시 대화형 쿼리의 최대 개수 | 쿼리 16개 | 프로젝트에서 Bigtable 외부 데이터 소스에 대한 동시 쿼리를 최대 16개까지 실행할 수 있습니다. |
원격 함수가 포함된 최대 동시 실행 쿼리 수 | 쿼리 10개 | 원격 함수를 사용하여 프로젝트당 쿼리를 최대 10개까지 동시에 실행할 수 있습니다. |
최대 동시 멀티 문 쿼리 수 | 멀티 문 쿼리 1,000개 | 프로젝트는 최대 1,000개의 동시 멀티 문 쿼리를 실행할 수 있습니다. |
UDF가 포함된 최대 동시 legacy SQL 쿼리 수 | 쿼리 6개 | 프로젝트는 사용자 정의 함수(UDF)를 사용하여 최대 6개의 동시 SQL 쿼리를 실행할 수 있습니다. 이 한도에는 대화형 및 일괄 쿼리가 모두 포함됩니다. UDF가 포함된 대화형 쿼리 역시 대화형 쿼리에 대한 동시 실행 한도에 합산됩니다. GoogleSQL 쿼리에는 이 한도가 적용되지 않습니다. |
일일 쿼리 크기 한도 | 무제한 | 기본적으로 일일 쿼리 크기 제한은 없습니다. 하지만 커스텀 할당량을 생성하여 사용자가 쿼리할 수 있는 데이터의 양을 설정함으로써 일일 쿼리 사용량 또는 사용자당 일일 쿼리 사용량을 제어할 수 있습니다. |
일일 대상 테이블 업데이트 한도 | 일일 최대 테이블 작업 수를 참조하세요. |
쿼리 작업의 대상 테이블 업데이트는 대상 테이블의 일일 최대 테이블 작업 수 한도로 집계됩니다. 대상 테이블 업데이트에는 Google Cloud 콘솔을 사용하거나 bq 명령줄 도구를 사용하거나 jobs.query 및 쿼리 유형 jobs.insert API 메서드를 호출하여 실행하는 쿼리로 수행되는 추가 작업 및 덮어쓰기 작업이 포함됩니다.
|
쿼리/멀티 문 쿼리 실행 시간 제한 | 6시간 | 쿼리 또는 멀티 문 쿼리는 최대 6시간 동안 실행된 후 실패합니다. 하지만 경우에 따라 쿼리가 재시도됩니다. 쿼리는 최대 3회 시도될 수 있으며 각 시도는 최대 6시간 동안 실행될 수 있습니다. 따라서 쿼리의 총 런타임이 6시간을 초과할 수 있습니다. |
쿼리당 참조되는 최대 리소스 개수 | 리소스 1,000개 |
완전히 확장하면 한 쿼리에서 최대 1,000개의 고유한 테이블, 고유한 뷰, 고유한 사용자 정의 함수, 고유한 테이블 함수를 참조할 수 있습니다. 이 한도에는 다음이 포함됩니다.
|
해결되지 않은 legacy SQL 쿼리 최대 길이 | 256KB |
해결되지 않은 legacy SQL 쿼리의 최대 길이는 256KB입니다. 쿼리가 더 길면 The query
is too large. 오류가 발생합니다. 이 한도를 초과하지 않으려면 큰 배열 또는 목록을 쿼리 매개변수로 교체하는 것이 좋습니다.
|
해결되지 않은 GoogleSQL 쿼리 최대 길이 | 1MB |
해결되지 않은 GoogleSQL 쿼리의 최대 길이는 1MB입니다. 쿼리가 더 길면 The query is too
large. 오류가 발생합니다. 이 한도를 초과하지 않으려면 큰 배열 또는 목록을 쿼리 매개변수로 교체하는 것이 좋습니다.
|
해결된 legacy SQL 및 GoogleSQL 쿼리 최대 길이 | 12MB | 해결된 쿼리 길이 제한에는 쿼리에서 참조된 모든 뷰와 와일드 카드 테이블 길이가 포함됩니다. |
최대 GoogleSQL 쿼리 매개변수 수 | 매개변수 10,000개 | GoogleSQL 쿼리에는 최대 10,000개의 매개변수가 포함될 수 있습니다. |
최대 요청 크기 | 10MB | 요청 크기는 쿼리 매개변수와 같은 추가 속성을 포함하여 최대 10MB까지 가능합니다. |
최대 응답 크기 | 10GB 압축 | 크기는 데이터의 압축비에 따라 달라집니다. 실제 응답 크기는 10GB보다 훨씬 더 클 수 있습니다. 대상 테이블에 대량의 쿼리 결과를 쓰는 경우 최대 응답 크기는 무제한입니다. |
BigQuery Omni 최대 쿼리 결과 크기 | 20GiB 비압축 | 최대 결과 크기는 Azure 또는 AWS 데이터를 쿼리할 때 20GiB 로컬 바이트입니다. 자세한 내용은 BigQuery Omni 제한사항을 참조하세요. |
최대 행 크기 | 100MB | 이 한도는 행 데이터의 내부 표현을 기준으로 하므로 최대 행 크기는 근사치입니다. 최대 행 크기 한도는 쿼리 작업 실행의 특정 단계에서 적용됩니다. |
테이블, 쿼리 결과 또는 뷰 정의의 최대 열 수 | 열 10,000개 | 테이블, 쿼리 결과 또는 뷰 정의 하나에 최대 10,000개의 열을 포함할 수 있습니다. |
BigQuery Omni 쿼리 결과 크기 | 1TB | 프로젝트의 총 쿼리 결과 크기는 1일 1TB입니다.
자세한 내용은 BigQuery Omni 제한사항을 참조하세요. |
주문형 가격의 최대 동시 슬롯 수 | 슬롯 2,000개 | 주문형 가격 책정을 사용하면 프로젝트에 동시 슬롯을 최대 2,000개까지 가질 수 있습니다. BigQuery 슬롯은 단일 프로젝트의 모든 쿼리 간에 공유됩니다. BigQuery는 쿼리를 가속화하기 위해 이 한도를 초과하여 버스팅할 수 있습니다. 현재 사용 중인 슬롯 수를 확인하려면 Cloud Monitoring을 사용한 BigQuery 모니터링을 참조하세요. |
주문형 가격 책정의 스캔 데이터당 최대 CPU 사용량 | 스캔된 MiB당 256CPU-초 |
주문형 가격 책정의 경우 쿼리에서 스캔 데이터에 대해 MiB당 최대 약 256개의 CPU 레코드를 사용할 수 있습니다. 처리되는 데이터 양에 대해 쿼리의 CPU 사용률이 너무 높으면 billingTierLimitExceeded 오류와 함께 쿼리가 실패합니다.
자세한 내용은 billingTierLimitExceeded를 참조하세요.
|
멀티 문 트랜잭션 테이블 변형 | 테이블 100개 | 트랜잭션은 최대 100개의 테이블에 있는 데이터를 변형할 수 있습니다. |
멀티 문 트랜잭션 파티션 수정사항 | 파티션 100,000개 수정 | 트랜잭션은 최대 100,000개의 파티션 수정을 수행할 수 있습니다. |
예약된 쿼리가 BigQuery Data Transfer Service 기능을 사용하더라도 전송에 해당되지 않으며 로드 작업 한도가 적용되지 않습니다.
내보내기 작업
bq
명령줄 도구, Google Cloud 콘솔 또는 내보내기 유형 jobs.insert
API 메서드를 사용하여 BigQuery에서 데이터를 내보내는 작업에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
내보낸 일일 최대 바이트 수 | 50TB |
공유 슬롯 풀을 사용하여 프로젝트에서 하루에 최대 50TB(테비바이트)의 데이터를 무료로 내보낼 수 있습니다. 내보낸 바이트 수에 대한 알림을 제공하는 Cloud Monitoring 알림 정책을 설정할 수 있습니다.
하루에 50TB(테비바이트)를 초과하는 데이터를 내보내려면 다음 중 하나를 수행하세요.
|
일일 최대 내보내기 횟수 | 내보내기 100,000회 |
프로젝트에서 하루에 최대 100,000개의 내보내기를 실행할 수 있습니다.
하루에 100,000개를 초과하는 내보내기를 실행하려면 다음 중 하나를 수행합니다.
|
단일 파일로 내보내는 최대 테이블 크기 | 1GB | 최대 1GB의 테이블 데이터를 단일 파일로 내보낼 수 있습니다. 1GB가 넘는 데이터를 내보내려면 와일드 카드를 사용하여 데이터를 여러 파일로 내보냅니다. 데이터를 파일 여러 개로 내보내면 파일 크기가 달라집니다. 경우에 따라 출력 파일의 크기가 1GB를 초과합니다. |
내보내기당 와일드 카드 URI 수 | URI 500개 | 내보내기 하나에 최대 500개의 와일드 카드 URI가 포함될 수 있습니다. |
현재 내보내기 작업 사용량 보기에 대한 자세한 내용은 현재 할당량 사용량 보기를 참조하세요.
로드 작업
Google Cloud 콘솔, bq
명령줄 도구 또는 부하 유형 jobs.insert
API 메서드를 사용하여 BigQuery에 데이터를 로드하는 경우 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
테이블당 일일 로드 작업 수 | 실패한 로드 작업을 포함한 로드 작업은 대상 테이블의 일일 최대 테이블 작업 수 제한에 포함됩니다. 표준 테이블 및 파티션을 나눈 테이블의 일일 최대 테이블 작업 수 제한에 대한 자세한 내용은 테이블을 참조하세요. | |
일일 로드 작업 수 | 작업 100,000개 | 프로젝트에서 하루에 최대 100,000개의 로드 작업을 실행할 수 있습니다. 실패한 로드 작업도 이 한도에 반영됩니다. |
테이블당 최대 열 수 | 열 10,000개 | 테이블 하나에 최대 10,000개의 열을 포함할 수 있습니다. |
로드 작업당 최대 크기 | 15TB | 모든 CSV, JSON, Avro, Parquet, ORC 입력 파일은 총 크기가 최대 15TB일 수 있습니다. |
작업 구성의 최대 소스 URI 수 | URI 10,000개 | 작업 구성 하나에 최대 10,000개의 소스 URI가 포함될 수 있습니다. |
로드 작업당 최대 파일 수 | 10,000,000개 파일 | 로드 작업 하나에 모든 와일드 카드 URI와 일치하는 모든 파일을 포함한 총 1,000만 개의 파일을 포함할 수 있습니다. |
소스 Cloud Storage 버킷의 최대 파일 수 | 파일 약 60,000,000개 | 로드 작업은 최대 60,000,000개까지 파일이 포함된 Cloud Storage 버킷에서 읽을 수 있습니다. |
로드 작업 실행 시간 제한 | 6시간 | 로드 작업이 6시간 넘게 실행되면 실패합니다. |
Avro: 파일 데이터 블록의 최대 크기 | 16MB | Avro 파일 데이터 블록의 크기는 16MB로 제한됩니다. |
CSV: 최대 셀 크기 | 100MB | CSV 셀의 최대 크기는 100MB입니다. |
CSV: 최대 행 크기 | 100MB | CSV 행의 최대 크기는 100MB입니다. |
CSV: 최대 파일 크기 - 압축 | 4GB | 압축된 CSV 파일의 크기는 4GB로 제한됩니다. |
CSV: 최대 파일 크기 - 비압축 | 5TB | 비압축 CSV 파일의 크기는 5TB로 제한됩니다. |
JSON: 최대 행 크기 | 100MB | JSON 행의 최대 크기는 100MB입니다. |
JSON: 최대 파일 크기 - 압축 | 4GB | 압축된 JSON 파일의 크기는 4GB로 제한됩니다. |
JSON: 최대 파일 크기 - 비압축 | 5TB | 비압축 JSON 파일의 크기는 5TB로 제한됩니다. |
잦은 업데이트로 인해 로드 작업 한도를 정기적으로 초과한다면 BigQuery로 데이터를 스트리밍하는 것이 좋습니다.
현재 로드 작업 사용량 보기에 대한 자세한 내용은 현재 할당량 사용량 보기를 참조하세요.
BigQuery Data Transfer Service 로드 작업 할당량 고려사항
BigQuery Data Transfer Service 전송으로 만든 로드 작업은 로드 작업의 BigQuery 할당량에 포함됩니다. 전송 및 다른 로드 작업으로 인해 quotaExceeded
오류가 발생하지 않도록 각 프로젝트에서 사용 설정할 전송량을 고려하는 것이 중요합니다.
다음 수식을 사용하여 전송에 필요한 로드 작업 수를 추정할 수 있습니다.
Number of daily jobs = Number of transfers x Number of tables x
Schedule frequency x Refresh window
각 항목의 의미는 다음과 같습니다.
Number of transfers
는 프로젝트에서 사용하는 전송 구성 수입니다.Number of tables
는 특정한 전송 유형에서 생성된 테이블 수입니다. 테이블 수는 전송 유형에 따라 다릅니다.- Campaign Manager 전송은 약 25개의 테이블을 만듭니다.
- Google Ads 전송은 약 60개의 테이블을 만듭니다.
- Google Ad Manager 전송은 약 40개의 테이블을 만듭니다.
- Google Play 전송은 약 25개의 테이블을 만듭니다.
- Search Ads 360 전송은 약 50개의 테이블을 만듭니다.
- YouTube 전송은 약 50개의 테이블을 만듭니다.
Schedule frequency
는 전송이 실행되는 빈도를 설명합니다. 각 전송 유형에 전송 실행 일정이 제공됩니다.Refresh window
는 데이터 전송에 포함될 일 수입니다. 1을 입력하는 경우 일일 백필은 없습니다.
복사 작업
표준 테이블, 테이블 클론 또는 테이블 스냅샷의 복사, 클론 또는 스냅샷을 만드는 작업을 포함하여 테이블 복사의 BigQuery 작업에 다음 한도가 적용됩니다.
이 한도는 Google Cloud 콘솔, bq
명령줄 도구 또는 복사 유형 jobs.insert
메서드를 사용하여 만든 작업에 적용됩니다.
복사 작업은 성공이나 실패 여부에 관계없이 이러한 한도에 포함됩니다.
한도 | 기본값 | 참고 |
---|---|---|
대상 테이블당 일일 복사 작업 수 | 일일 테이블 작업 수를 참조하세요. | |
일일 복사 작업 수 | 작업 100,000개 | 프로젝트에서 하루에 최대 100,000개의 복사 작업을 실행할 수 있습니다. |
대상 테이블당 일일 리전 간 복사 작업 수 | 작업 100개 | 프로젝트에서 대상 테이블의 리전 간 복사 작업은 하루에 최대 100개까지 실행할 수 있습니다. |
일일 리전 간 복사 작업 수 | 작업 2,000개 | 프로젝트에서 하루에 최대 2,000개의 리전 간 복사 작업을 실행할 수 있습니다. |
복사할 소스 테이블 수 | 소스 테이블 1,200개 | 복사 작업당 최대 1,200개의 소스 테이블에서 복사할 수 있습니다. |
현재 복사 작업 사용량 보기에 대한 자세한 내용은 복사 작업 - 현재 할당량 사용 보기를 참조하세요.
데이터 세트 복사에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
소스 데이터 세트의 최대 테이블 수 | 테이블 20,000개 | 한 소스 데이터 세트에 최대 20,000개의 테이블이 있을 수 있습니다. |
동일 리전의 대상 데이터 세트에 복사 가능한 실행당 최대 테이블 수 | 테이블 20,000개 | 프로젝트에서 실행당 20,000개의 테이블을 같은 리전에 있는 대상 데이터 세트에 복사할 수 있습니다. |
다른 리전의 대상 데이터 세트에 복사 가능한 실행당 최대 테이블 수 | 테이블 1,000개 | 프로젝트에서 실행당 1,000개의 테이블을 다른 리전에 있는 대상 데이터 세트에 복사할 수 있습니다. 예를 들어 테이블 8,000개가 포함된 데이터 세트의 리전 간 복사를 구성하는 경우 BigQuery Data Transfer Service는 자동으로 8개의 실행을 순차적으로 생성합니다. 첫 번째 실행에서 테이블 1,000개가 복사됩니다. 24시간 후 두 번째 실행에서 1,000개의 테이블을 복사합니다. 이 프로세스는 데이터 세트의 모든 테이블이 복사될 때까지 계속되며, 데이터 세트당 최대 테이블 수는 20,000개입니다. |
예약
예약에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
EU 리전의 총 슬롯 수 | 슬롯 2,000개 |
Google Cloud Console을 사용하여 EU 멀티 리전에서 구매할 수 있는 최대 BigQuery 슬롯 수입니다.
Google Cloud 콘솔에서 할당량 보기 |
미국 리전의 총 슬롯 수 | 슬롯 4,000개 |
Google Cloud Console을 사용하여 미국 멀티 리전에서 구매할 수 있는 최대 BigQuery 슬롯 수입니다.
Google Cloud 콘솔에서 할당량 보기 |
asia-northeast1, asia-northeast3, australia-southeast1, europe-west2, northamerica-northeast1 리전의 총 슬롯 수입니다. | 슬롯 1,000개 |
Google Cloud 콘솔을 사용하여 나열된 각 리전에서 구매할 수 있는 최대 BigQuery 슬롯 수입니다.
Google Cloud 콘솔에서 할당량 보기 |
Omni 리전의 총 슬롯 수(aws-us-east-1 및 azure-eastus2) | 슬롯 100개 |
Google Cloud 콘솔을 사용하여 Omni 리전에서 구매할 수 있는 최대 BigQuery 슬롯 수
Google Cloud 콘솔에서 할당량 보기 |
다른 모든 리전의 총 슬롯 수 | 슬롯 500개 |
Google Cloud Console을 사용하여 서로 다른 리전에서 구매할 수 있는 최대 BigQuery 슬롯 수
Google Cloud 콘솔에서 할당량 보기 |
예약에 다음 한도가 적용됩니다.
한도 | 값 | 참고 |
---|---|---|
슬롯 예약의 관리 프로젝트 수 | 조직당 5개의 프로젝트 | 특정 위치/리전의 슬롯에 대한 예약 또는 활성 약정을 포함할 수 있는 조직 내 최대 프로젝트 수입니다. |
데이터 세트
BigQuery 데이터 세트에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 데이터 세트 수 | 무제한 | 프로젝트에서 사용할 수 있는 데이터 세트 수에는 제한이 없습니다. |
데이터 세트당 테이블 수 | 무제한 | API 호출을 사용할 때 데이터 세트의 테이블 수가 50,000개에 근접하면 열거 성능이 저하됩니다. Google Cloud 콘솔은 각 데이터 세트에 대해 최대 50,000개의 테이블을 표시할 수 있습니다. |
데이터 세트에 대한 액세스 제어 목록(ACL)의 승인된 리소스 수 | 2,500개의 리소스 | 데이터 세트의 액세스제어 목록(ACL)에는 승인된 뷰, 승인된 데이터 세트, 승인된 함수를 포함하여 최대 2,500개의 승인된 리소스가 포함될 수 있습니다. 승인된 뷰 수가 많아 이 한도를 초과하는 경우 뷰를 승인된 데이터 세트로 그룹화하는 것이 좋습니다. |
데이터 세트별 10초당 데이터 세트 업데이트 작업 수 | 작업 5개 |
프로젝트에서 10초마다 최대 5개의 데이터 세트 업데이트 작업을 수행할 수 있습니다.
데이터 세트 업데이트 한도에는 다음에서 수행되는 모든 메타데이터 업데이트 작업이 포함됩니다.
|
데이터 세트 설명의 최대 길이 | 16,384자(영문 기준) | 데이터 세트에 설명을 추가할 때 최대 16,384자(영문 기준)의 텍스트를 입력할 수 있습니다. |
테이블
모든 테이블
모든 BigQuery 테이블에 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
열 설명의 최대 길이 | 1,024자(영문 기준) | 열에 설명을 추가할 때 최대 1,024자(영문 기준)의 텍스트를 입력할 수 있습니다. |
중첩 레코드의 최대 깊이 | 수준 15개 |
RECORD 유형 열은 하위 레코드로 불리는 중첩된 RECORD 유형을 포함할 수 있습니다. 최대 중첩 깊이 제한은 15개 수준입니다.
이 제한은 레코드가 스칼라 기반이든 배열 기반(반복)이든 상관없이 적용됩니다.
|
표준 테이블
BigQuery 표준(기본 제공) 테이블에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
일일 테이블 수정 횟수 | 수정 1,500회 |
프로젝트에서 수정, 데이터 추가, 테이블 자르기 등 하루에 테이블당 최대 1,500개의 테이블을 수정할 수 있습니다. 이 한도에는 대상 테이블에 데이터를 추가하거나 대상 테이블을 덮어쓰거나 DML, DML 문은 일일 테이블 수정 횟수에 포함되지만 이 한도에 의해 제한되지는 않습니다. DML 한도에 대한 자세한 내용은 DML 문을 참조하세요. |
테이블당 최대 테이블 메타데이터 업데이트 작업 속도 | 10초당 작업 5개 |
프로젝트에서 10초마다 테이블당 최대 5개의 테이블 메타데이터 업데이트 작업을 수행할 수 있습니다. 이 한도는 다음에서 수행되는 모든 테이블 메타데이터 업데이트 작업에 적용됩니다.
이 한도를 초과하면 이 한도로 집계되는 작업을 식별하려면 로그를 검사하면 됩니다. |
테이블당 최대 열 수 | 열 10,000개 | 각 테이블, 쿼리 결과 또는 뷰 정의에 최대 10,000개의 열을 포함할 수 있습니다. |
외부 테이블
데이터가 Parquet, ORC, Avro, CSV 또는 JSON 형식으로 Cloud Storage에 저장되는 BigQuery 테이블에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
외부 테이블당 최대 소스 URI 수 | URI 10,000개 | 각 외부 테이블에 최대 10,000개의 소스 URI가 포함될 수 있습니다. |
외부 테이블당 최대 파일 수 | 10,000,000개 파일 | 외부 테이블 하나에 모든 와일드 카드 URI와 일치하는 모든 파일을 포함해 최대 1,000만 개의 파일을 포함할 수 있습니다. |
외부 테이블당 Cloud Storage에 저장된 최대 데이터 크기 | 600TB | 외부 테이블 하나의 모든 입력 파일에서 최대 600테라바이트까지 사용할 수 있습니다. 이 한도는 Cloud Storage에 저장되는 파일 크기에 적용됩니다. 이 크기는 쿼리 가격 책정 공식에 사용되는 크기와 같지 않습니다. 외부에서 파티션을 나눈 테이블의 경우 파티션 프루닝 후에 이 한도가 적용됩니다. |
소스 Cloud Storage 버킷의 최대 파일 수 | 파일 약 60,000,000개 | 외부 테이블은 최대 약 60,000,000개의 파일을 포함하는 Cloud Storage 버킷을 참조할 수 있습니다. 외부에서 파티션을 나눈 테이블의 경우 파티션 프루닝 전에 이 한도가 적용됩니다. |
파티션을 나눈 테이블
BigQuery 파티션을 나눈 테이블에는 다음 한도가 적용됩니다.
대상 파티션에 추가하거나 덮어쓰거나 DML DELETE
, INSERT
, MERGE
, TRUNCATE TABLE
또는 UPDATE
문을 사용하여 테이블의 데이터에 영향을 주는 모든 로드 작업, 복사 작업, 쿼리 작업의 합계에 파티션 한도가 적용됩니다.
DML 문은 파티션 한도에 포함되지만 이에 국한되지 않습니다. DML 한도에 대한 자세한 내용은 DML 문을 참조하세요.
단일 작업이 여러 파티션에 영향을 미칠 수 있습니다. 예를 들어 DML 문은 여러 파티션의 데이터를 업데이트할 수 있습니다(수집 시간 및 파티션을 나눈 테이블). 쿼리 작업과 로드 작업은 여러 파티션에 쓸 수 있지만 이는 파티션을 나눈 테이블에 한합니다.
BigQuery는 작업이 소비하는 한도를 결정할 때 작업의 영향을 받은 파티션 수를 사용합니다. 스트리밍 삽입은 이 한도에 영향을 미치지 않습니다.
파티션을 나눈 테이블의 한도를 초과하지 않는 전략에 대한 자세한 내용은 할당량 오류 문제 해결을 참조하세요.
한도 | 기본값 | 참고 |
---|---|---|
파티션을 나눈 테이블당 파티션 수 | 파티션 4,000개 | 파티션을 나눈 각 테이블에는 최대 4,000개의 파티션을 포함할 수 있습니다. 이 한도를 초과하면 파티션 나누기 외에 추가로 또는 파티션 나누기를 대신해서 클러스터링을 사용하는 것이 좋습니다. |
단일 작업으로 수정되는 파티션 수 | 파티션 4,000개 | 각 쿼리 또는 로드 작업에서 최대 4,000개의 파티션에 영향을 미칠 수 있습니다. BigQuery에서 4,000개 이상의 파티션을 수정하려고 시도하는 쿼리 또는 로드 작업을 거부합니다. |
수집 시간으로 파티션을 나눈 테이블당 하루 파티션 수정 횟수 | 수정 5,000회 | 프로젝트에서 수정이 추가되거나, 데이터가 업데이트되거나, 수집 시간으로 파티션을 나눈 테이블을 자르든 하루에 최대 5,000개의 파티션을 수정할 수 있습니다. DML 문은 일일 파티션 수정 횟수에 포함되지만 이 한도의 제약은 없습니다. DML 한도에 대한 자세한 내용은 DML 문을 참조하세요. |
열로 파티션을 나눈 테이블당 하루 파티션 수정 횟수 | 수정 30,000회 |
프로젝트에서 열로 파티션을 나눈 테이블 하나의 파티션을 하루 최대 30,000회 수정할 수 있습니다. |
테이블별 10초당 수정 횟수 | 수정 50회 | 프로젝트는 10초마다 파티션을 나눈 테이블당 최대 50회의 수정을 실행할 수 있습니다. |
범위 파티션 나누기의 가능한 범위 수 | 범위 10,000개 | 범위로 파티션을 나눈 테이블에는 최대 10,000개의 가능한 범위가 포함될 수 있습니다. 이 한도는 테이블을 만들 때 파티션 사양에 적용됩니다. 테이블을 만든 후에는 한도가 실제 파티션 수에도 적용됩니다. |
테이블 스냅샷
BigQuery 테이블 스냅샷에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 동시 테이블 스냅샷 작업 수 | 작업 100개 | 프로젝트에서 최대 100개의 동시 테이블 스냅샷 작업을 실행할 수 있습니다. |
일일 최대 테이블 스냅샷 작업 수 | 작업 50,000개 | 프로젝트에서 하루에 최대 50,000개의 테이블 스냅샷 작업을 실행할 수 있습니다. |
테이블당 일일 최대 테이블 스냅샷 작업 수 | 작업 50개 | 프로젝트에서 하루에 테이블당 최대 50개의 테이블 스냅샷 작업을 실행할 수 있습니다. |
테이블 스냅샷별 10초당 최대 메타데이터 업데이트 수 | 업데이트 5개 | 프로젝트에서 10초마다 테이블 스냅샷의 메타데이터를 최대 5회 업데이트할 수 있습니다. |
뷰
뷰 및 구체화된 뷰에는 다음 할당량 및 한도가 적용됩니다.
논리적 뷰
BigQuery 표준 뷰에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 중첩 뷰 수준 수 | 수준 16개 |
BigQuery에서는 중첩 뷰를 최대 16개 수준까지 지원합니다. 수준이 16개를 초과하면 INVALID_INPUT 오류가 반환됩니다.
|
뷰 정의에 사용되는 GoogleSQL 쿼리의 최대 길이 | 256,000자(영문 기준) | 뷰를 정의하는 GoogleSQL 쿼리의 텍스트는 최대 256,000자(영문 기준)일 수 있습니다. |
데이터 세트당 최대 승인된 뷰 수 | 데이터 세트를 참조하세요. |
구체화된 뷰
BigQuery 구체화된 뷰에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
기본 테이블 참조(같은 데이터 세트) | 구체화된 뷰 20개 | 같은 데이터 세트의 구체화된 뷰 최대 20개에서 각 기본 테이블을 참조할 수 있습니다. |
기본 테이블 참조(같은 프로젝트) | 구체화된 뷰 100개 | 같은 프로젝트의 구체화된 뷰 최대 100개에서 각 기본 테이블을 참조할 수 있습니다. |
기본 테이블 참조(전체 조직) | 구체화된 뷰 500개 | 전체 조직의 구체화된 뷰 최대 500개에서 각 기본 테이블을 참조할 수 있습니다. |
데이터 세트당 최대 승인된 뷰 수 | 데이터 세트를 참조하세요. |
색인
BigQuery 색인에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
리전별 프로젝트당 일일 CREATE INDEX DDL 문 수 | 작업 500개 | 프로젝트가 한 리전 내에서 매일 최대 500개의 CREATE INDEX DDL 작업을 실행할 수 있습니다. |
테이블당 일일 색인 DDL 문 수 | 작업 20개 | 프로젝트에서 테이블당 매일 최대 20개의 CREATE INDEX 또는 DROP INDEX DDL 작업을 실행할 수 있습니다. |
예약에서 실행되지 않는 색인 생성에 허용되는 조직당 최대 테이블 데이터 총 크기 | 멀티 리전에서 100TB, 다른 모든 리전에서 20TB |
조직의 색인이 있는 테이블의 전체 크기가 리전 한도(US 및 EU 멀티 리전은 100TB, 다른 모든 리전은 20TB) 미만이면 테이블의 색인을 만들 수 있습니다. 색인 관리 작업이 자체 예약에서 실행되는 경우 이 한도가 적용되지 않습니다.
|
루틴
루틴에 다음 할당량과 한도가 적용됩니다.
사용자 정의 함수
GoogleSQL 쿼리의 임시 및 영구 사용자 정의 함수(UDF)에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
행당 최대 출력 | 5MB | 단일 행을 처리할 때 자바스크립트 UDF가 출력할 수 있는 최대 데이터 양은 약 5MB입니다. |
자바스크립트 UDF가 있는 최대 동시 legacy SQL 쿼리 수 | 쿼리 6개 | 프로젝트에는 자바스크립트의 UDF가 포함된 동시 실행 legacy SQL 쿼리가 최대 6개까지 있을 수 있습니다. 이 한도에는 대화형 및 일괄 쿼리가 모두 포함됩니다. UDF가 포함된 대화형 쿼리 역시 대화형 쿼리에 대한 동시 비율 한도에 합산됩니다. GoogleSQL 쿼리에는 이 한도가 적용되지 않습니다. |
쿼리당 최대 자바스크립트 UDF 리소스 수 | 리소스 50개 | 쿼리 작업 하나에 인라인 코드 blob 또는 외부 파일과 같은 자바스크립트 UDF 리소스를 최대 50개까지 포함할 수 있습니다. |
인라인 코드 blob 최대 크기 | 32KB | UDF의 인라인 코드 blob은 최대 크기가 32KB입니다. |
각 외부 코드 리소스의 최대 크기 | 1MB | 각 자바스크립트 코드 리소스의 최대 크기는 1MB입니다. |
영구 UDF에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
UDF 이름의 최대 길이 | 256자(영문 기준) | UDF 이름의 최대 길이는 256자(영문 기준)입니다. |
최대 인수 개수 | 인수 256개 | UDF 하나에 최대 256개의 인수가 포함될 수 있습니다. |
인수 이름 최대 길이 | 128자(영문 기준) | UDF 인수 이름의 길이는 최대 128자(영문 기준)입니다. |
UDF 참조 체인의 최대 깊이 | 참조 16개 | UDF 참조 체인 하나에 최대 16개의 참조 깊이가 사용될 수 있습니다. |
STRUCT 유형 인수 또는 출력의 최대 깊이
|
수준 15개 |
STRUCT 유형 UDF 인수 또는 출력 하나에 최대 15개 수준의 깊이를 사용할 수 있습니다.
|
STRUCT 유형 인수 또는 출력의 최대 필드 수(UDF당)
|
필드 1,024개 |
UDF 하나에서 STRUCT 유형 인수 및 출력의 필드를 최대 1,024개 포함할 수 있습니다.
|
CREATE FUNCTION 문으로 된 최대 자바스크립트 라이브러리 수
|
라이브러리 50개 |
CREATE FUNCTION 문 하나에 최대 50개의 자바스크립트 라이브러리가 포함될 수 있습니다.
|
포함된 자바스크립트 라이브러리 경로의 최대 길이 | 5,000자(영문 기준) | UDF에 포함된 자바스크립트 라이브러리 경로의 최대 길이는 5,000자(영문 기준)입니다. |
UDF별 10초당 최대 업데이트 속도 | 업데이트 5개 | 프로젝트에서 10초마다 UDF를 최대 5회 업데이트할 수 있습니다. |
데이터 세트당 최대 승인된 UDF 수 | 데이터 세트를 참조하세요. |
원격 함수
BigQuery의 원격 함수에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
원격 함수가 포함된 최대 동시 실행 쿼리 수 | 쿼리 10개 | 원격 함수를 사용하여 프로젝트당 쿼리를 최대 10개까지 동시에 실행할 수 있습니다. |
최대 입력 크기 | 5MB | 단일 행의 모든 입력 인수의 최대 총 크기는 5MB입니다. |
HTTP 응답 크기 한도(Cloud Functions 1세대) | 10MB | Cloud 함수 1세대의 HTTP 응답 본문은 최대 10MB입니다. 이 값을 초과하면 쿼리가 실패합니다. |
HTTP 응답 크기 한도(Cloud Functions 2세대 또는 Cloud Run) | 15MB | Cloud 함수 2세대 또는 Cloud Run의 HTTP 응답 본문은 최대 15MB입니다. 이 값을 초과하면 쿼리가 실패합니다. |
최대 HTTP 호출 시간 제한(Cloud Functions 1세대) | 9분 | Cloud 함수 1세대에 개별 HTTP 호출의 고유한 제한 시간을 직접 설정할 수 있지만 최대 시간 제한은 9분입니다. Cloud 함수 1세대에 설정된 시간 제한을 초과하면 제한된 횟수만큼 재시도한 후에 HTTP 호출과 쿼리가 실패합니다. |
HTTP 호출 시간 제한(Cloud Functions 2세대 또는 Cloud Run) | 20분 | Cloud 함수 2세대 또는 Cloud Run에 대한 개별 HTTP 호출의 시간 제한입니다. 이 값을 초과하면 제한된 횟수만큼 재시도한 후에 HTTP 호출과 쿼리가 실패합니다. |
테이블 함수
BigQuery 테이블 함수에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
테이블 함수 이름 최대 길이 | 256자(영문 기준) | 테이블 함수 이름의 최대 길이는 256자(영문 기준)입니다. |
인수 이름 최대 길이 | 128자(영문 기준) | 테이블 함수 인수 이름의 최대 길이는 128자(영문 기준)입니다. |
최대 인수 개수 | 인수 256개 | 테이블 함수 하나에 최대 256개의 인수가 포함될 수 있습니다. |
테이블 함수 참조 체인의 최대 깊이 | 참조 16개 | 테이블 함수 참조 체인 하나에 최대 16개의 참조 깊이가 사용될 수 있습니다. |
STRUCT 유형 인수 또는 출력의 최대 깊이 |
수준 15개 |
테이블 함수의 STRUCT 인수 하나에 최대 15개 수준의 깊이를 사용할 수 있습니다. 마찬가지로, 테이블 함수 출력의 STRUCT 레코드도 최대 15개 수준의 깊이를 사용할 수 있습니다.
|
테이블 함수당 STRUCT 유형의 인수 또는 반환 테이블 최대 필드 수 |
필드 1,024개 |
테이블 함수의 STRUCT 인수 하나에 최대 1,024개의 필드를 포함할 수 있습니다.
마찬가지로, 테이블 함수 출력의 STRUCT 레코드도 최대 1,024개의 필드를 사용할 수 있습니다.
|
반환 테이블의 최대 열 수 | 열 1,024개 | 테이블 함수로 반환된 테이블 하나에 최대 1,024개의 열을 포함할 수 있습니다. |
반환 테이블 열 이름의 최대 길이 | 128자(영문 기준) | 반환 테이블 열 이름의 최대 길이는 128자(영문 기준)입니다. |
테이블 함수별 10초당 최대 업데이트 수 | 업데이트 5개 | 프로젝트에서 10초마다 테이블 함수를 최대 5회 업데이트할 수 있습니다. |
Apache Spark 저장 프로시저
Apache Spark용 BigQuery 저장 프로시저에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 동시 저장 프로시져 쿼리의 최대 개수 | 50 | 각 프로젝트에 대해 최대 50개까지 동시 저장 프로시져 쿼리를 실행할 수 있습니다. |
동시 CPU의 최대 개수 | 12,000 | 프로젝트당 최대 12,000개의 동시 CPU를 사용할 수 있습니다.
다음 위치를 제외하고 각 프로젝트의 최대 2,400개의 동시 CPU를 사용할 수 있습니다.
이러한 위치에서는 프로젝트마다 위치당 최대 500개의 동시 CPU를 사용할 수 있습니다. 멀티 리전 위치와 동일한 지리적 영역에 있는 단일 리전 위치에서 동시 쿼리를 실행하는 경우 쿼리에서 동일한 동시 CPU 할당량을 사용할 수 있습니다. |
표준 영구 디스크의 최대 총 크기 | 204.8TB | 프로젝트당 각 위치당 최대 204.8TB의 표준 영구 디스크를 사용할 수 있습니다. 멀티 리전 위치와 동일한 지리적 영역에 있는 단일 리전 위치에서 동시 쿼리를 실행하는 경우 쿼리에서 동일한 표준 영구 디스크 할당량을 사용할 수 있습니다. |
DML
BigQuery 데이터 조작 언어(DML) 문에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
일일 DML 문 수 | 무제한 |
DML 문은 일일 테이블 수정 횟수(또는 파티션을 나눈 테이블의 일일 파티션을 나눈 테이블 수정 횟수)에 포함됩니다.
그러나 프로젝트에서 하루에 실행할 수 있는 DML 문 수는 무제한이며, 일일 테이블 수정 할당량(또는 파티션을 나눈 수정 할당량)의 제약을 받지 않습니다.
테이블 수정(또는 파티션을 나눈 테이블 수정)에 대한 일일 한도가 소진된 후에는 로드 작업 또는 복사 작업 같은 비DML 수정에 대해서는 오류가 뜨지만, DML 문은 오류 없이 계속해서 수행할 수 있습니다. 예를 들어 mytable 이라는 수집 시간으로 파티션을 나눈 테이블이 있다고 가정합니다. 데이터를 mytable$20210720 에 추가하는 복사 작업 3,000개와 INSERT 를 사용하여 데이터를 mytable$20210720 에 추가하는 쿼리 DML 작업 2,000개를 실행하면 파티션 수정 일일 한도에 도달합니다. 이 한도에 도달하면 추가적인 복사 작업은 실패하지만 DELETE , INSERT , MERGE , TRUNCATE TABLE , UPDATE 문 등 DML을 기반한 쿼리 작업은 계속해서 성공합니다. DML 문에는 다음과 같은 제한사항이 있습니다.
|
테이블당 동시 변형 DML 문 수 | 문 2개 |
BigQuery는 각 테이블에 대해 최대 2개의 동시 변형 DML 문(UPDATE , DELETE , MERGE )을 실행합니다. 테이블의 추가 변형 DML 문은 큐에 추가됩니다.
|
큐에 추가된 테이블당 변형 DML 문 수 | 문 20개 | 테이블에는 실행 대기 중인 큐에 최대 20개의 변형 DML 문이 있을 수 있습니다. 테이블에 추가 변형 DML 문을 제출하면 해당 문이 실패합니다. |
DML 문의 최대 큐 대기 시간 | 6시간 | 대화형 우선순위 DML 문은 큐에서 최대 6시간 동안 대기할 수 있습니다. 6시간 후에 문이 실행되지 않으면 문이 실패합니다. |
DML 문 변형에 대한 자세한 내용은 INSERT
DML 동시 실행 및 UPDATE, DELETE, MERGE
DML 동시 실행을 참조하세요.
멀티 문 쿼리
BigQuery의 멀티 문 쿼리에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
누적 시간 제한 | 24시간 | 멀티 문 쿼리의 누적 시간 제한은 24시간입니다. |
문 시간 제한 | 6시간 | 멀티 문 쿼리 내 개별 문의 시간 제한은 6시간입니다. |
쿼리의 재귀적 CTE
BigQuery의 재귀적 공통 테이블 표현식(CTE)에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
반복 한도 | 반복 500회 | 재귀적 CTE는 반복을 이 횟수만큼 실행할 수 있습니다. 이 한도를 초과하면 오류가 발생합니다. 반복 한도를 해결하려면 반복 한도 오류 문제 해결을 참조하세요. |
행 수준 보안
BigQuery 행 수준 액세스 정책에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
테이블당 최대 행 액세스 정책 수 | 정책 100개 | 테이블 하나에 최대 100개의 행 액세스 정책이 있을 수 있습니다. |
쿼리당 최대 행 액세스 정책 수 | 정책 100개 | 쿼리 하나에 최대 100개의 행 액세스 정책이 있을 수 있습니다. |
정책별 10초당 최대 CREATE /DROP DDL 문 수 |
문 5개 |
프로젝트에서 10초마다 행 액세스 정책 리소스당 최대 5개의 CREATE 또는 DROP 문을 만들 수 있습니다.
|
테이블별 10초당 DROP ALL ROW ACCESS POLICIES 문 수 |
문 5개 |
프로젝트에서 10초마다 테이블당 최대 5개의 DROP ALL ROW ACCESS POLICIES 문을 만들 수 있습니다.
|
데이터 정책
열 수준 동적 데이터 마스킹에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
정책 태그당 최대 데이터 정책 수 | 3 |
BI Engine
BigQuery BI Engine에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
위치당 프로젝트당 최대 예약 크기(SQL 인터페이스) | 250GB | Looker Studio 이외의 비즈니스 인텔리전스(BI) 도구와 함께 BI Engine을 사용하는 경우에 적용됩니다.
프로젝트의 최대 예약 용량 상향 조정을 요청할 수 있습니다. 대부분의 리전에서 예약을 상향 조정할 수 있으며 처리하는 데 3일에서 일주일이 걸릴 수 있습니다. |
위치당 프로젝트당 최대 예약 크기(Looker Studio) | 100GB | Looker Studio에서 BI Engine을 사용할 때 적용됩니다. BI Engine은 전체 테이블 대신 쿼리에서 사용하는 열만 인메모리로 로드하므로 이 한도는 쿼리하는 테이블의 크기에 영향을 미치지 않습니다. |
테이블당 최대 데이터 모델 크기(Looker Studio) | 10GB | Looker Studio에서 BI Engine을 사용할 때 적용됩니다. 위치당 프로젝트당 100GB의 예약이 있는 경우 BI Engine은 테이블당 예약을 10GB로 제한합니다. 이용 가능한 나머지 예약은 프로젝트의 나머지 테이블에 사용됩니다. |
테이블당 최대 파티션 수(Looker Studio) | 500 파티션 | Looker Studio용 BI Engine은 테이블당 최대 500개의 파티션을 지원합니다. |
쿼리당 최대 행 수(Looker Studio) | 1억 5천만 | Looker Studio용 BI Engine은 쿼리 복잡성에 따라 쿼리 데이터 1억 5천만 행을 지원합니다. |
Analytics Hub
Analytics Hub에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
프로젝트당 최대 데이터 교환 수 | 교환 500개 | 프로젝트당 최대 500개의 데이터 교환을 만들 수 있습니다. |
데이터 교환당 최대 목록 수 | 목록 1000개 | 데이터 교환당 최대 1,000개의 목록을 만들 수 있습니다. |
공유 데이터 세트당 최대 연결된 데이터 세트 수 | 연결된 데이터 세트 1000개 | 모든 Analytics Hub 구독자는 공유 데이터 세트당 최대 1,000개의 연결된 데이터 세트를 포함할 수 있습니다. |
API 할당량 및 한도
BigQuery API 요청에 이러한 할당량과 한도가 적용됩니다.
BigQuery API
BigQuery API(코어) 요청에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
일일 요청 수 | 무제한 |
프로젝트에서 하루에 무제한으로 BigQuery API 요청을 수행할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
분당 최대 tabledata.list 바이트
|
멀티 리전에서 7.5GB, 다른 모든 리전에서 3.7GB |
프로젝트에서 us 및 eu 멀티 리전의 tabledata.list 를 통해 테이블 행 데이터를 분당 최대 7.5GB까지 반환하고, 다른 모든 리전에서 분당 3.7GB의 테이블 행 데이터를 반환할 수 있습니다. 이 할당량은 읽는 테이블이 포함된 프로젝트에 적용됩니다. jobs.getQueryResults 를 포함하고 jobs.query 및 jobs.insert 에서 결과를 가져온 다른 API도 이 할당량을 사용할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
BigQuery API(코어) 요청에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
메서드별 사용자별 초당 최대 API 요청 수 | 요청 100개 | 사용자는 API 메서드에 초당 최대 100개의 API 요청을 실행할 수 있습니다. 사용자가 메서드에 100개를 초과하는 초당 요청을 할 경우 제한이 있을 수 있으나 스트리밍 삽입에는 이 한도가 적용되지 않습니다. |
사용자당 최대 동시 API 요청 수 | 요청 300개 | 사용자가 300개를 초과하는 동시 요청을 할 경우 제한이 있을 수 있으나 스트리밍 삽입에는 이 한도가 적용되지 않습니다. |
최대 요청 헤더 크기 | 16KiB |
BigQuery API 요청 크기는 요청 URL과 모든 헤더를 포함하여 최대 16KiB까지 가능합니다. 이 한도는 요청 본문(예: POST 요청)에는 적용되지 않습니다.
|
초당 최대 jobs.get 요청 수
|
요청 1,000개 |
프로젝트에서 jobs.get 요청을 초당 최대 1,000개까지 실행할 수 있습니다.
|
최대 jobs.query 응답 크기
|
20MB |
기본적으로 결과 페이지당 jobs.query 에서 반환되는 최대 데이터 행 수에는 제한이 없습니다. 그러나 최대 응답 크기는 20MB로 제한됩니다. maxResults 매개변수를 사용하여 반환할 행 수를 변경할 수 있습니다.
|
초당 최대 projects.list 요청 수
|
요청 2개 |
프로젝트에서 projects.list 요청을 초당 최대 2개까지 실행할 수 있습니다.
|
초당 최대 tabledata.list 요청 수
|
요청 1,000개 |
프로젝트에서 tabledata.list 요청을 초당 최대 1,000개까지 실행할 수 있습니다.
|
tabledata.list 요청에서 반환되는 초당 최대 행 수
|
행 150,000개 |
tabledata.list 요청을 사용하여 프로젝트에서 초당 최대 150,000개의 행을 반환할 수 있습니다. 이 한도는 읽는 테이블이 포함된 프로젝트에 적용됩니다.
|
tabledata.list 응답당 최대 행 수
|
행 100,000개 |
tabledata.list 호출은 최대 100,000개의 테이블 행을 반환할 수 있습니다.
자세한 내용은 API를 사용하여 결과 페이지 나누기을 참조하세요.
|
초당 최대 tables.insert 요청 수
|
요청 10개 |
프로젝트에서 초당 최대 10개의 tables.insert 요청을 실행할 수 있습니다.
tables.insert 메서드는 데이터 세트에 빈 테이블을 새로 만듭니다. 이 한도에는 CREATE TABLE 과 같이 테이블을 만드는 SQL 문과 대상 테이블에 결과를 쓰는 쿼리가 포함됩니다.
|
BigQuery Connection API
BigQuery Connection API 요청에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
분당 읽기 요청 | 분당 요청 1,000개 |
프로젝트에서 연결 데이터를 읽는 BigQuery Connection API 메서드에 분당 최대 1,000개의 요청을 보낼 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
분당 쓰기 요청 | 요청 100개/분 |
프로젝트에서 연결을 만들거나 업데이트하는 BigQuery Connection API 메서드에 분당 최대 100개의 요청을 보낼 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
BigQuery Migration API
BigQuery Migration API(미리보기)에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
일괄 SQL 변환을 위한 개별 파일 크기 | 10MB |
각 개별 소스와 메타데이터 파일은 최대 10MB입니다.
dwh-migration-dumper 명령줄 도구에서 생성된 메타데이터 zip 파일에는 이 한도가 적용되지 않습니다.
|
일괄 SQL 변환의 소스 파일 총 크기 | 1GB | Cloud Storage에 업로드되는 모든 입력 파일의 총 크기는 최대 1GB입니다. 여기에는 모든 소스 파일과 모든 메타데이터 파일(포함하도록 선택한 경우)이 포함됩니다. |
대화형 SQL 변환의 입력 문자열 크기 | 1MB | 대화형 SQL 변환에 입력하는 문자열은 1MB를 초과하면 안 됩니다. |
대화형 SQL 변환의 최대 구성 파일 크기 | 50MB |
Cloud Storage의 개별 메타데이터 파일(압축) 및 YAML 구성 파일은 50MB를 초과할 수 없습니다. 파일 크기가 50MB를 초과하면 대화형 변환기는 변환 중에 구성 파일을 건너뛰고 오류 메시지를 생성합니다. 메타데이터 파일 크기를 줄이는 한 가지 방법은 —database 또는 –schema 플래그를 사용하여 메타데이터를 생성할 때 데이터베이스를 필터링하는 것입니다.
|
다음 할당량이 BigQuery Migration API에 적용됩니다. 대부분의 경우 다음 기본값이 적용됩니다. 프로젝트의 기본값은 다를 수 있습니다.
할당량 | 기본값 | 참고 |
---|---|---|
분당 EDWMigration 서비스 목록 요청 수 사용자별 분당 EDWMigration 서비스 목록 요청 수 |
12,000개 요청 2,500개 요청 |
프로젝트에서 분당 최대 12,000개의 Migration API List 요청을 실행할 수 있습니다. 각 사용자는 분당 최대 2,500개의 Migration API List 요청을 실행할 수 있습니다. Google Cloud 콘솔에서 할당량 보기 |
분당 EDWMigration 서비스 가져오기 요청 수 사용자별 분당 EDWMigration 서비스 가져오기 요청 수 |
25,000개 요청 2,500개 요청 |
프로젝트에서 분당 최대 25,000개의 Migration API Get 요청을 실행할 수 있습니다. 각 사용자는 분당 최대 2,500개의 Migration API Get 요청을 실행할 수 있습니다 Google Cloud 콘솔에서 할당량 보기 |
분당 EDWMigration Service 기타 요청 수 사용자별 분당 EDWMigration Service 기타 요청 |
25개 요청 5개 요청 |
프로젝트에서 분당 최대 25개의 Migration API 요청을 실행할 수 있습니다. 각 사용자는 분당 최대 5개의 Migration API 요청을 실행할 수 있습니다. Google Cloud 콘솔에서 할당량 보기 |
분당 대화형 SQL 변환 요청 수 사용자별 분당 대화형 SQL 변환 요청 수 |
200개 요청 50개 요청 |
프로젝트에서 분당 최대 200개의 SQL 변환 서비스 요청을 실행할 수 있습니다. 각 사용자는 분당 최대 50개의 SQL 변환 서비스 요청을 실행할 수 있습니다. Google Cloud 콘솔에서 할당량 보기 |
BigQuery Reservation API
BigQuery Reservation API 요청에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
리전별 분당 요청 | 요청 100개 |
프로젝트에서 BigQuery Reservation API 메서드에 리전별로 분당 최대 100개의 호출을 수행할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
리전별 분당 SearchAllAssignments 호출 수
|
요청 100개 |
프로젝트에서 SearchAllAssignments 메서드에 리전별로 분당 최대 100개의 호출을 수행할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
각 사용자의 리전별 분당 SearchAllAssignments 요청 수
|
요청 10개 |
각 사용자는 리전별로 분당 최대 10개의 SearchAllAssignments 메서드를 호출할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 (Google Cloud 콘솔 검색결과에서 사용자당을 검색하세요.) |
BigQuery Data Policy API
Data Policy API(미리보기)에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 dataPolicy.list 호출 수 |
프로젝트별 분당 요청 400개 조직별 분당 요청 600개 |
|
최대 dataPolicy.testIamPermissions 호출 수
|
프로젝트별 분당 요청 400개 조직별 분당 요청 600개 |
|
최대 읽기 요청 수 |
프로젝트별 분당 요청 1,200개 조직별 분당 요청 1,800개 |
여기에는 dataPolicy.get 및 dataPolicy.getIamPolicy 에 대한 호출이 포함됩니다.
|
최대 쓰기 요청 수 |
프로젝트별 분당 요청 600개 조직별 분당 요청 900개 |
여기에는 다음에 대한 호출이 포함됩니다. |
IAM API
BigQuery에서 Identity and Access Management 기능을 사용해 IAM 정책을 검색하고 설정하며 IAM 권한을 테스트할 때 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
분당 IAM 정책 요청 수 | 요청 3,000개 |
프로젝트에서 초당 최대 3,000개의 IAM 요청을 보낼 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
사용자별 분당 IAM 정책 요청 수 | 요청 1,500개 |
각 사용자는 프로젝트별로 분당 최대 1,500개의 IAM 요청을 보낼 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
Storage Read API
BigQuery Storage Read API 요청에는 다음 할당량이 적용됩니다.
할당량 | 기본값 | 참고 |
---|---|---|
사용자별 분당 읽기 데이터 영역 요청 수 | 요청 25,000개 |
각 사용자는 프로젝트별로 분당 최대 25,000개의 ReadRows 호출을 수행할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
사용자별 분당 읽기 제어 영역 요청 수 | 요청 5,000개 |
각 사용자는 프로젝트별로 분당 최대 5,000개의 Storage Read API 메타데이터 작업 호출을 수행할 수 있습니다. 메타데이터 호출에는 CreateReadSession 및 SplitReadStream 메서드가 포함됩니다.
Google Cloud 콘솔에서 할당량 보기 |
BigQuery Storage Read API 요청에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
최대 행/필터 길이 | 1MB |
Storage Read API CreateReadSession 호출을 사용하는 경우 행 또는 필터당 최대 길이가 1MB로 제한됩니다.
|
최대 직렬화된 데이터 크기 | 128MB |
Storage Read API ReadRows 호출을 사용할 때 개별 ReadRowsResponse 메시지의 데이터 직렬화 표현은 128MB를 넘지 않아야 합니다.
|
최대 동시 연결 수 | 멀티 리전에서 2,000개, 리전에서 400개 |
us 및 eu 멀티 리전에서 프로젝트당 최대 2,000개의 동시 ReadRows 연결을 열 수 있으며, 다른 리전에서 400개의 동시 ReadRows 연결을 열 수 있습니다. 경우에 따라 이 한도보다 적은 수의 동시 연결로 제한될 수 있습니다.
|
Storage Write API
Storage Write API 요청에는 다음 할당량이 적용됩니다. 다음 할당량을 폴더 수준에서 적용할 수 있습니다. 그런 다음 이 할당량이 집계되어 모든 하위 프로젝트에 공유됩니다. 이 구성을 사용 설정하려면 Cloud Customer Care에 문의하세요.
할당량 한도 상향을 요청할 계획이라면 신속하게 처리할 수 있도록 요청에 할당량 오류 메시지를 포함하세요.
할당량 | 기본값 | 참고 |
---|---|---|
동시 연결 수 | 멀티 리전에서 10,000개, 리전에서 1000개 |
동시 연결 할당량은 BigQuery 데이터세트 리소스가 포함된 프로젝트가 아니라 Storage Write API 요청을 시작하는 클라이언트 프로젝트를 기준으로 합니다. 시작 프로젝트는 API 키 또는 서비스 계정과 연결된 프로젝트입니다. 프로젝트는 Cloud Monitoring에서 프로젝트의 사용 할당량 및 한도 측정항목을 볼 수 있습니다. 리전을 기준으로 동시 연결 한도 이름을 선택합니다. 옵션은 |
처리량 | 멀티 리전에서 초당 3GB의 처리량, 리전에서 초당 300MB 처리량 |
us 및 eu 멀티 리전에서 최대 3GBps까지, 프로젝트당 다른 리전에서 최대 300MBps까지 스트리밍할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 Cloud Monitoring에서 프로젝트의 사용 할당량 및 한도 측정항목을 볼 수 있습니다. 리전을 기준으로 처리량 한도 이름을 선택합니다. 옵션은 |
CreateWriteStream 요청
|
프로젝트당 4시간마다 스트림 30,000개 |
프로젝트당 4시간당 최대 30,000개까지 CreateWriteStream 을 호출할 수 있습니다. 정확히 하나의 시맨틱스가 필요하지 않은 경우 기본 스트림을 사용하는 것이 좋습니다.
Google Cloud 콘솔에서 할당량 보기 |
대기 중인 스트림 바이트 | 멀티 리전에 10TB, 리전에 1TB |
트리거하는 모든 커밋의 경우 us 및 eu 멀티 리전에서 최대 10TB까지, 다른 리전에서 최대 1TB까지 커밋할 수 있습니다.
Google Cloud 콘솔에서 할당량 보기 |
Storage Write API 요청에는 다음 한도가 적용됩니다.
한도 | 기본값 | 참고 |
---|---|---|
일괄 커밋 | 테이블당 스트림 10,000개 |
BatchCommitWriteStream 호출마다 스트림을 최대 10,000개까지 커밋할 수 있습니다.
|
AppendRows 요청 크기 |
10MB | 최대 요청 크기는 10MB입니다. |
스트리밍 삽입
다음 할당량과 한도는 기존 스트리밍 API를 사용하여 데이터를 BigQuery로 스트리밍할 때 적용됩니다.
이러한 한도를 초과하지 않는 전략에 대한 자세한 내용은 할당량 오류 문제 해결을 참조하세요.
이 할당량을 초과하면 quotaExceeded
오류가 발생합니다.
한도 | 기본값 | 참고 |
---|---|---|
us 및 eu 멀티 리전의 프로젝트별 초당 최대 행 수
|
1GB/초 |
프로젝트는 초당 1GB까지 스트리밍할 수 있습니다. 이 할당량은 특정 멀티 리전 내에서 누적됩니다. 즉, 멀티 리전에 포함된 특정 프로젝트의 모든 테이블에 스트리밍되는 초당 바이트의 합계가 1GB로 제한됩니다.
이 한도를 초과하면 필요한 경우 Cloud Customer Care에 문의하여 할당량 증가를 요청할 수 있습니다. 할당량을 늘려야 하는 경우 최소 2주 전에 상향 조정을 요청하세요. 특히 할당량을 크게 늘려야 하는 경우 할당량 상향 조정을 완료하는 데 시간이 걸립니다. |
다른 모든 위치의 프로젝트별 초당 최대 바이트 수 | 초당 300MB |
프로젝트는
이 한도를 초과하면 필요한 경우 Cloud Customer Care에 문의하여 할당량 증가를 요청할 수 있습니다. 할당량을 늘려야 하는 경우 최소 2주 전에 상향 조정을 요청하세요. 특히 할당량을 크게 늘려야 하는 경우 할당량 상향 조정을 완료하는 데 시간이 걸립니다. |
최대 행 크기 | 10MB |
이 값을 초과하면 invalid 오류가 발생합니다.
|
HTTP 요청 크기 한도 | 10MB |
이 값을 초과하면 내부적으로 요청의 HTTP JSON이 내부 데이터 구조로 변환됩니다. 변환된 데이터 구조에는 자체적으로 적용되는 크기 한도가 있습니다. 결과로 도출되는 내부 데이터 구조의 크기를 예측하기는 어렵지만 HTTP 요청을 10MB 이하로 유지하면 내부 한도에 도달할 확률이 낮습니다. |
요청당 최대 행 수 | 행 50,000개 | 최대 500행을 사용하는 것이 좋습니다. 일괄 처리로 성능과 처리량을 일정 정도 높일 수 있지만 요청당 지연 시간은 증가합니다. 요청당 행 수 및 각 요청의 오버헤드가 너무 적으면 수집의 효율성이 떨어질 수 있습니다. 요청당 행 수가 너무 많은 경우 처리량이 감소할 수 있습니다. 대표 데이터(스키마 및 데이터 크기)를 사용해 실험하여 데이터에 적합한 배치 크기를 결정합니다. |
insertId 필드 길이
|
128자(영문 기준) |
이 값을 초과하면 invalid 오류가 발생합니다.
|
추가 스트리밍 할당량은 할당량 상향 요청을 참조하세요.