할당량 및 한도

BigQuery는 프로젝트당 적절한 할당량을 적용하고 최대 요청 수신 비율을 제한합니다. 구체적인 정책은 리소스 가용성, 사용자 프로필, 서비스 사용 기록, 기타 요인에 따라 다르며 사전 통보 없이 변경될 수 있습니다.

아래 목록에서는 현재 시스템의 비율 한도 및 할당량 한도를 간략히 설명합니다.

쿼리 작업

대화형 쿼리를 실행하여 자동으로 만들어지는 쿼리 작업 그리고 jobs.query 및 쿼리 유형 jobs.insert 메소드 호출을 사용하여 프로그래매틱 방식으로 제출되는 작업에는 다음 한도가 적용됩니다.

  • 주문형 대화형 쿼리에 적용되는 동시 비율 한도 — 동시 쿼리 50개

쿼리 캐시에서 반환된 결과가 있는 쿼리와 테스트 실행 쿼리는 이 한도에 포함되지 않습니다. 쿼리 작업에서 --dry_run 플래그를 사용하거나 dryRun 속성을 설정하여 테스트 실행 쿼리를 지정할 수 있습니다.

이 한도는 프로젝트 수준에서 적용됩니다. 한도를 상향 조정하려면 지원팀 또는 영업팀에 문의하세요.

  • Cloud Bigtable 외부 데이터 소스에 대한 주문형 대화형 쿼리에 적용되는 동시 비율 한도 — 동시 쿼리 4개

Cloud Bigtable 외부 데이터 소스에 대한 동시 쿼리는 4개로 제한됩니다.

  • 맞춤 설정 함수(UDF)가 포함된 legacy SQL 쿼리에 대한 동시 비율 한도 — 동시 쿼리 6개

UDF가 포함된 legacy SQL 쿼리에 대한 동시 비율 한도에는 대화형 및 일괄 쿼리가 모두 포함됩니다. UDF가 포함된 대화형 쿼리는 대화형 쿼리에 대한 동시 비율 한도에도 계산됩니다. 이 제한은 표준 SQL 쿼리에는 적용되지 않습니다.

  • 일일 쿼리 크기 제한 — 기본적으로 무제한

커스텀 할당량을 설정하여 사용자가 쿼리할 수 있는 데이터의 양을 제한할 수 있습니다.

  • 일일 대상 테이블 업데이트 제한 — 테이블당 하루 1,000회 업데이트

쿼리 작업의 대상 테이블에는 테이블당 하루 1,000회 업데이트 한도가 적용됩니다. 대상 테이블 업데이트에는 콘솔, 기본 BigQuery 웹 UI, bq 명령줄 도구를 사용하는 쿼리를 통해 또는 jobs.query 및 쿼리 유형 jobs.insert API 메소드를 호출하여 수행되는 추가 작업과 덮어쓰기 작업이 포함됩니다.

  • 쿼리 실행 시간 제한 — 6시간

  • 쿼리당 참조되는 최대 테이블 개수 — 1,000개

  • 해결되지 않은 legacy SQL 쿼리 최대 길이 — 256KB

  • 해결된 legacy SQL 쿼리 최대 길이 — 12MB

  • 해결되지 않은 표준 SQL 쿼리 최대 길이 — 1MB

해결된 쿼리 길이 제한에는 쿼리에서 참조된 모든 뷰와 와일드 카드 테이블 길이가 포함됩니다.

  • 최대 응답 크기 — 압축 후 128MB1

1크기는 데이터의 압축비에 따라 달라집니다. 실제 응답 크기는 128MB보다 훨씬 더 클 수 있습니다.

대상 테이블에 대량의 쿼리 결과를 쓰는 경우 최대 응답 크기는 무제한입니다.

  • 최대 행 크기 — 100MB2

2이 제한은 행 데이터의 내부 표현을 기준으로 하므로 최대 행 크기 제한은 근사치입니다. 최대 행 크기 제한은 쿼리 작업 실행의 특정 단계에서 적용됩니다.

  • 테이블, 쿼리 결과 또는 뷰 정의의 최대 열 수 — 10,000개

  • 주문형 가격의 프로젝트당 최대 동시 슬롯 수 — 2,000개

주문형 쿼리의 기본 슬롯 수는 단일 프로젝트의 모든 쿼리 간에 공유됩니다. 일반적으로 한 번에 100GB 미만의 쿼리를 처리하는 경우 2,000개 슬롯을 모두 사용할 가능성은 높지 않습니다.

사용 중인 슬롯 수를 확인하려면 Stackdriver를 사용한 BigQuery 모니터링을 참조하세요. 2,000개 이상의 슬롯이 필요한 경우 영업 담당자에게 문의하여 정액제가 더 잘 적합한지 확인해 보세요.

  • Cloud Bigtable 외부 데이터 소스를 대상으로 한 최대 동시 쿼리 수 — 4개

SQL 쿼리의 맞춤 설정 함수에 적용되는 제한에 대한 자세한 내용은 UDF 제한을 참조하세요.

로드 작업

명령줄 도구, 콘솔 또는 기본 BigQuery 웹 UI를 사용한 데이터 로드로 자동 생성된 작업에는 다음 한도가 적용됩니다. 또한 로드 유형 jobs.insert API 메소드를 사용하여 프로그래매틱 방식으로 제출된 로드 작업에도 이 한도가 적용됩니다.

BigQuery로 데이터를 로드하는 경우 다음 한도가 적용됩니다.

  • 테이블당 일일 로드 작업 — 1,000개(실패 포함)
  • 프로젝트당 일일 로드 작업 — 50,000개(실패 포함)
  • 테이블당 하루 1,000개의 로드 작업 한도는 늘릴 수 없습니다.
  • 행 및 셀 크기 제한:
    데이터 형식 최대 한도
    CSV 100MB(행 및 셀 크기)
    JSON 100MB(행 크기)
  • 테이블당 최대 열 수 — 10,000개
  • 최대 파일 크기:
    파일 형식 압축 비압축
    CSV 4GB 5TB
    JSON 4GB 5TB
    Avro 압축된 Avro 파일은 지원되지 않지만 압축된 데이터 블록은 지원됩니다. BigQuery는 DEFLATE 및 Snappy 코덱을 지원합니다. 5TB(파일 헤더의 경우 1MB)
  • 로드 작업당 최대 크기 — CSV, JSON, Avro, Parquet, ORC의 모든 입력 파일에서 15TB
  • 작업 구성에서 최대 소스 URI 수 — URI 10,000개
  • 로드 작업당 최대 파일 수 — 모든 와일드 카드 URI와 일치하는 모든 파일을 포함하여 총 1,000만 개
  • 로드 작업 실행 시간 제한 — 6시간
  • 미국 기반의 데이터세트가 아니라면 데이터세트의 위치와 동일한 리전에 있는 Cloud Storage 버킷에서 데이터를 로드해야 합니다(버킷은 다중 리전 버킷이거나 데이터세트와 동일한 리전의 리전 버킷임). 미국 기반 데이터세트에는 모든 리전의 데이터를 로드할 수 있습니다.

자세한 내용은 BigQuery로 데이터 로드하기 소개를 참조하세요.

복사 작업

BigQuery의 테이블 복사에는 다음과 같은 한도가 적용됩니다. 명령줄 도구, 콘솔 또는 기본 BigQuery 웹 UI를 사용한 데이터 복사로 자동 생성된 작업에는 다음 한도가 적용됩니다. 또한 복사 유형 jobs.insert API 메소드를 사용하여 프로그래매틱 방식으로 제출된 복사 작업에도 이 한도가 적용됩니다.

  • 대상 테이블당 일일 복사 작업 — 1,000개(실패 포함)
  • 프로젝트당 일일 복사 작업 — 10,000개(실패 포함)

내보내기 작업

BigQuery에서 데이터를 내보내는 작업에는 다음과 같은 한도가 적용됩니다. 명령줄 도구, 콘솔 또는 기본 BigQuery 웹 UI를 사용한 데이터 내보내기로 자동 생성된 작업에는 다음 한도가 적용됩니다. 또한 로드 유형 jobs.insert API 메소드를 사용하여 프로그래매틱 방식으로 제출된 내보내기 작업에도 이 한도가 적용됩니다.

  • 일일 내보내기 — 프로젝트당 내보내기 50,000회 및 하루 최대 10TB(10TB 데이터 한도는 모든 내보내기에 걸쳐 누적됨)
  • 와일드 카드 URI — 내보내기 당 와일드 카드 URI 500개

데이터세트 한도

데이터세트에는 다음 한도가 적용됩니다.

  • 프로젝트당 데이터세트 수 — 무제한
    프로젝트당 데이터세트의 수에는 할당량이 적용되지 않지만 프로젝트의 데이터세트 수가 수천 개에 근접하면 기본 UI 성능이 저하되고 데이터세트 나열 속도가 느려집니다.
  • 데이터세트당 테이블 수 — 무제한
    데이터세트의 테이블이 50,000개 이상이 되면 이를 열거하는 속도가 느려집니다. API 호출 또는 기본 BigQuery 웹 UI를 사용할 경우 열거 성능이 저하됩니다. 현재까지 GCP Console에서 BigQuery 웹 UI는 데이터세트당 테이블을 50,000개만 표시할 수 있습니다. 기본 BigQuery 웹 UI의 성능 향상을 위해서 ?minimal 매개변수를 사용하여 프로젝트당 표시되는 테이블 수를 30,000개로 제한할 수 있습니다. 다음 형식으로 기본 BigQuery 웹 UI URL에 매개변수를 추가합니다. https://bigquery.cloud.google.com/queries/[PROJECT_NAME]?minimal
  • 데이터세트의 액세스제어 목록(ACL)에서 최대 승인된 뷰 수 — 2,500개
    승인된 뷰를 만들어 소스 데이터 액세스를 제한할 수 있습니다. 승인된 뷰는 사용자가 뷰를 쿼리할 때 사용자에게 보이고 싶지 않은 열을 제외하는 SQL 쿼리를 사용하여 만들어집니다. 데이터세트의 액세스제어 목록(ACL)에 최대 2,500개의 승인된 뷰를 추가할 수 있습니다.
  • 최대 데이터세트 메타데이터 업데이트 작업 빈도 — 데이터세트당 10초마다 작업 5회
    데이터세트 메타데이터 업데이트 한도에는 콘솔, 기본 BigQuery 웹 UI, bq 명령줄 도구를 사용하거나 datasets.insert, datasets.patch 또는 datasets.update API 메소드를 호출하여 수행된 모든 메타데이터 업데이트 작업이 포함됩니다.
  • 데이터세트 설명의 최대 길이 — 16,384자(영문 기준)
    데이터세트에 설명을 추가할 때 최대 16,384자(영문 기준)의 텍스트를 입력할 수 있습니다.

테이블 한도

BigQuery 테이블에는 다음 한도가 적용됩니다.

모든 테이블

  • 열 설명의 최대 길이 — 16,384자(영문 기준)

열에 설명을 추가할 때 최대 16,384자(영문 기준)의 텍스트를 입력할 수 있습니다.

표준 테이블

  • 일일 최대 테이블 작업 횟수 — 1,000회

테이블에 데이터 추가하기, 테이블 덮어쓰기, DML INSERT 문을 사용하여 테이블에 데이터 쓰기 등 하루에 테이블당 수행할 수 있는 최대 작업은 1,000회로 제한됩니다.

최대 테이블 작업 수에는 대상 테이블에 데이터를 추가하거나 대상 테이블을 덮어쓰거나 DML INSERT 문을 사용하여 테이블에 데이터를 쓰는 모든 로드 작업, 복사 작업, 쿼리 작업의 합계가 포함됩니다.

예를 들어 mytable에 데이터를 추가하는 500개의 복사 작업과 mytable에 데이터를 추가하는 500개의 쿼리 작업을 실행하는 경우 할당량에 도달하게 됩니다.

  • 최대 테이블 메타데이터 업데이트 작업 빈도 — 테이블당 10초마다 작업 5회

테이블 메타데이터 업데이트 한도에는 콘솔, 기본 BigQuery 웹 UI, bq 명령줄 도구를 사용하거나 tables.insert, tables.patch 또는 tables.update API 메소드를 호출하여 수행된 모든 메타데이터 업데이트 작업이 포함됩니다. 이 한도는 작업 출력에도 적용됩니다.

  • 테이블, 쿼리 결과 또는 뷰 정의의 최대 열 수 — 10,000개

파티션을 나눈 테이블

  • 파티션을 나눈 테이블당 최대 파티션 수 — 4,000개

  • 단일 작업으로 수정되는 최대 파티션 수 — 2,000개

각 작업(쿼리 또는 로드)에서 최대 2,000개의 파티션에 영향을 미칠 수 있습니다. 2,000개를 초과하는 파티션에 영향을 미치는 모든 쿼리 또는 로드 작업은 Google BigQuery에서 거부됩니다.

  • 테이블당 일일 최대 파티션 수정 횟수 — 5,000회

파티션을 나눈 테이블에서 일일 파티션 수정 횟수는 총 5,000회로 제한됩니다. 파티션에 데이터를 추가하거나 파티션 데이터를 덮어쓰는 작업을 사용하여 파티션을 수정할 수 있습니다. 파티션을 수정하는 작업에는 로드 작업, 파티션에 결과를 쓰는 쿼리, 파티션의 데이터를 수정하는 DML 문(INSERT, DELETE, UPDATE, MERGE)이 포함됩니다.

단일 작업으로 2개 이상의 파티션이 영향을 받을 수 있습니다. 예를 들어 DML 문은 여러 파티션의 데이터를 업데이트할 수 있습니다(내부 데이터화 시간 및 파티션을 나눈 테이블). 쿼리 작업과 로드 작업은 여러 파티션에 쓸 수 있지만 이는 파티션을 나눈 테이블에 한합니다. BigQuery는 작업이 소비하는 할당량을 결정할 때 작업의 영향을 받은 파티션 수를 사용합니다. 스트리밍 삽입은 이 할당량에 영향을 미치지 않습니다.

  • 최대 파티션 작업 빈도 — 10초마다 파티션 작업 50회

뷰 한도

  • 최대 중첩 뷰 수준 수 — 16개

BigQuery에서는 중첩 뷰를 최대 16개 수준까지 지원합니다. 수준이 16개를 초과하면 INVALID_INPUT 오류가 반환됩니다.

  • 뷰 정의에 사용되는 표준 SQL 쿼리의 최대 길이 — 256,000자(영문 기준)

뷰를 만들 때 표준 SQL 쿼리의 텍스트에는 최대 256,000자(영문 기준)까지 사용할 수 있습니다.

  • 데이터세트의 액세스제어 목록(ACL)에서 최대 승인된 뷰 수 — 2,500개

승인된 뷰를 만들어 소스 데이터 액세스를 제한할 수 있습니다. 승인된 뷰는 사용자가 뷰를 쿼리할 때 사용자에게 보이고 싶지 않은 열을 제외하는 SQL 쿼리를 사용하여 만들어집니다. 데이터세트의 액세스제어 목록(ACL)에 최대 2,500개의 승인된 뷰를 추가할 수 있습니다.

UDF 한도

SQL 쿼리의 맞춤 설정 함수에는 다음 한도가 적용됩니다.

  • 단일 행을 처리할 때 자바스크립트 UDF가 출력하는 데이터 양 — 약 5MB 이하.
  • 맞춤 설정 함수(UDF)가 포함된 legacy SQL 쿼리의 동시 비율 한도 — 6개 동시 쿼리
  • UDF가 포함된 legacy SQL 쿼리에 대한 동시 비율 한도에는 대화형 및 일괄 쿼리가 모두 포함됩니다. UDF가 포함된 대화형 쿼리는 대화형 쿼리에 대한 동시 비율 한도에도 계산됩니다. 이 제한은 표준 SQL 쿼리에는 적용되지 않습니다.

  • 쿼리 작업이 포함할 수 있는 자바스크립트 UDF 리소스 수는 최대 50개입니다(인라인 코드 blob 또는 외부 파일).
  • 각 인라인 코드 blob 크기는 최대 32KB로 제한됩니다.
  • 각 외부 코드 리소스 크기는 최대 1MB로 제한됩니다.

데이터 조작 언어(DML) 문

DML 문에는 다음 한도가 적용됩니다.

  • 테이블당 일일 INSERT, UPDATE, DELETE, MERGE 문의 최대 총 수 — 1,000개

MERGE 문은 여러 개의 INSERT, UPDATE, DELETE 절을 포함한 경우에도 DML 문 1개로 계산됩니다.

BigQuery ML 한도

BigQuery ML 문 및 함수를 사용하는 표준 SQL 쿼리 작업에 다음 한도가 적용됩니다.

  • CREATE MODEL 문을 사용하는 쿼리 수 — 쿼리 1,000개
    • 하루에 프로젝트당 CREATE MODEL 쿼리 1,000개로 제한됩니다.

스트리밍 삽입

BigQuery로 데이터를 스트리밍하는 데는 다음 한도가 적용됩니다.

  • 최대 행 크기: 1MB. 이 값을 초과하는 경우 invalid 오류가 발생합니다.
  • HTTP 요청 크기 한도: 10MB. 이 값을 초과하는 경우 invalid 오류가 발생합니다.
  • 초당 최대 행: 프로젝트별 초당 100,000행. 이 양을 초과하는 경우 quotaExceeded 오류가 발생합니다. 테이블별 초당 최대 행 수도 100,000행입니다.
    하나의 테이블에서 이 할당량을 모두 사용하거나 프로젝트의 여러 테이블로 할당량을 분할할 수 있습니다.
  • 요청당 최대 행: 요청당 10,000행. 최대 500개 행을 사용하는 것이 좋습니다. 일괄 처리로 성능과 처리량을 일정 정도 높일 수 있지만 요청당 지연 시간은 증가합니다. 너무 적은 요청당 행 수 및 각 요청의 오버헤드로 인해 내부 데이터화의 효율성이 떨어질 수 있습니다. 요청당 행 수가 너무 많은 경우 처리량이 감소할 수 있습니다.

    요청당 약 500개의 행을 사용하는 것이 좋지만 대표 데이터를 사용한 실험(스키마 및 데이터 크기)을 통해 이상적인 일괄 처리 크기를 결정할 수 있습니다.
  • 초당 최대 바이트: 테이블별로 초당 100MB. 이 양을 초과하는 경우 quotaExceeded 오류가 발생합니다.

프로젝트에 더 많은 스트리밍 데이터 할당량이 필요한 경우 Google Cloud Platform Console 페이지에서 요청할 수 있습니다. 50,000행 단위로 스트리밍 데이터의 커스텀 할당량을 설정할 수 있습니다. 대개 영업일 기준 2~3일 내에 답변을 받을 수 있습니다.

API 요청

모든 API 요청

모든 BigQuery API 요청에 다음 한도가 적용됩니다.

  • 사용자별 초당 API 요청 — 100개
    초당 100개를 초과하는 요청을 할 경우 조절이 이루어질 수 있습니다. 이 제한은 스트리밍 삽입에는 적용되지 않습니다.
  • 사용자당 동시 API 요청: 300개
    사용자당 300개를 초과하는 동시 요청을 할 경우 조절이 이루어질 수 있습니다. 이 제한은 스트리밍 삽입에는 적용되지 않습니다.

tabledata.list 요청

tabledata.list 메소드는 지정된 행 조합에서 테이블 데이터를 검색합니다. tabledata.list 요청에는 다음 한도가 적용됩니다.

  • 프로젝트별 tabledata.list 쿼리의 최대 개수: 500개/초
    tabledata.list를 호출하는 경우 프로젝트별로 초당 최대 500개의 쿼리를 제출할 수 있습니다.
  • tabledata.list 호출에서 반환되는 프로젝트별 초당 최대 바이트: 60MB/초
    tabledata.list를 호출하는 경우 프로젝트별로 초당 최대 60MB의 테이블 행 데이터를 반환할 수 있습니다. 이 한도는 읽는 테이블이 포함된 프로젝트에 적용됩니다.
  • tabledata.list 호출에서 반환되는 프로젝트별 초당 최대 행 수: 150,000/초
    tabledata.list를 호출하는 경우 프로젝트별로 초당 최대 150,000개의 테이블 행을 반환할 수 있습니다. 이 한도는 읽는 테이블이 포함된 프로젝트에 적용됩니다.

tables.insert 요청

tables.insert 메소드는 데이터세트에 빈 테이블을 새로 만듭니다. tables.insert 요청에는 다음 한도가 적용됩니다.

  • 프로젝트별 초당 최대 요청: 10개 : tables.insert를 호출하는 경우 프로젝트별로 초당 최대 10개의 요청을 만들 수 있습니다. 이 한도에는 CREATE TABLE DDL 문과 같이 테이블을 만드는 문, 그리고 대상 테이블에 결과를 쓰는 쿼리가 포함됩니다.

projects.list 요청

projects.list 메소드는 사용자에게 액세스 권한이 부여된 모든 프로젝트를 나열합니다. projects.list 요청에는 다음 한도가 적용됩니다.

  • 프로젝트별 초당 최대 요청: 2개 : projects.list를 호출하는 경우 프로젝트별로 초당 최대 2개의 요청을 만들 수 있습니다.

jobs.get 요청

jobs.get 메소드는 특정 작업에 대한 정보를 반환합니다. jobs.get 요청에는 다음 한도가 적용됩니다.

  • 프로젝트별 초당 최대 요청: 1,000개 : jobs.get을 호출하는 경우 프로젝트별로 초당 최대 1,000개의 요청을 만들 수 있습니다.

할당량은 언제 보충되나요?

일일 할당량은 비율을 제한하는 동작을 유도하기 위해 정기적인 간격으로 온종일 보충됩니다. 할당량이 소진되었을 때 장시간 중단되지 않도록 간헐적인 보충도 이루어집니다. 할당량은 하루에 한 번 전체적으로 보충되는 것보다는 대개 몇 분 단위로 제공되는 양이 더 많습니다.

오류 코드

할당량 및 한도 오류는 403 또는 400 HTTP 응답 코드를 반환합니다. 전체 오류 코드 목록 및 문제해결 단계는 오류 문제해결을 참조하세요.

이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

다음에 대한 의견 보내기...

도움이 필요하시나요? 지원 페이지를 방문하세요.