BigQuery 가격 책정

BigQuery 가격 책정에 대한 자세한 내용은 이 페이지를 참조하세요.

BigQuery ML에 대한 자세한 내용은 BigQuery ML 가격 책정 페이지를 참조하세요.

BigQuery Data Transfer Service에 대한 자세한 내용은 BigQuery Data Transfer Service 가격 책정 페이지를 참조하세요.

개요

BigQuery는 고객이 요구하는 기술 사양과 예산에 맞춰 확장할 수 있는 유연한 가격 옵션을 제공합니다.

스토리지 비용은 BigQuery에 저장되는 데이터 양을 기준으로 합니다. 스토리지 요금은 다음과 같습니다.

  • 활성 - 지난 90일 동안 수정한 테이블 또는 파티션에 저장된 데이터에 대한 월별 요금입니다.
  • 장기 - 지난 90일 동안 수정하지 않은 테이블 또는 파티션에 저장된 데이터에 대한 월별 요금으로 요금이 더 낮습니다.

쿼리 비용의 경우 두 가격 모델 중에서 선택할 수 있습니다.

  • 주문형 - 가장 유연한 옵션입니다. 주문형 가격은 실행한 각 쿼리에서 처리된 데이터 양을 기준으로 산정됩니다.
  • 정액제 - 예측 가능한 가격 옵션으로 예산을 정해 놓은 고객에게 적합합니다. 정액제 고객은 쿼리 처리를 위한 전용 리소스를 구매하며 개별 쿼리에 대한 요금이 청구되지 않습니다.

스토리지 및 쿼리 가격 책정에 대한 자세한 내용은 Google Cloud Platform SKU를 참조하세요. SKU 페이지에서는 주문형 쿼리 가격을 분석 가격이라고 지칭합니다.

가격 책정 요약

다음은 BigQuery 가격을 요약한 표입니다. 이 작업에는 BigQuery의 할당량 및 한도가 적용됩니다.

요금 청구 방식

고객이 생성하는 각 프로젝트에는 결제 계정이 연결됩니다. 프로젝트에서 실행되는 BigQuery 작업으로 발생한 요금은 연결된 결제 계정으로 청구됩니다. BigQuery 스토리지 요금도 연결된 결제 계정으로 청구됩니다.

결제 데이터 분석 방법

BigQuery 비용 및 추세는 GCP Console의 Cloud 결제 보고서 페이지에서 확인할 수 있습니다. 보고서로 결제 데이터를 분석하는 방법에 대한 자세한 내용은 결제 보고서로 비용 추세 보기를 참조하세요.

BigQuery의 결제 데이터 분석 관련 정보는 Cloud Billing 문서BigQuery에 결제 데이터 내보내기를 참조하세요.

무료 작업

다음 표에서는 모든 위치에서 무료로 사용 가능한 BigQuery 작업을 보여줍니다. 이 작업에는 BigQuery의 할당량 및 한도가 적용됩니다.

작업 세부정보
데이터 로드

Cloud Storage에서 BigQuery로 데이터를 로드할 때 로드 작업에 대한 요금은 청구되지 않지만, Cloud Storage 내 데이터 저장에 대한 요금은 청구됩니다. 자세한 내용은 Cloud Storage 가격 책정 페이지의 데이터 스토리지를 참조하세요. 데이터가 BigQuery에 로드되면 BigQuery의 스토리지 가격 책정이 적용됩니다. 자세한 내용은 BigQuery에 데이터 로드를 참조하세요.

BigQuery에서 데이터세트를 만들 때 데이터 위치를 선택해야 합니다. US를 선택하면, 다른 모든 리전에 있는 Cloud Storage 버킷에서 데이터세트의 테이블에 데이터를 로드할 수 있습니다. 현재 다른 리전에서 미국 데이터세트로 데이터 로드 시 인터넷 이그레스는 무료로 사용할 수 있습니다.

US 이외의 위치를 선택하는 경우 다음 중 하나를 수행해야 합니다.

  • 해당 리전의 Cloud Storage 버킷에서 데이터를 로드합니다. 버킷은 데이터세트와 동일 리전에 있는 리전 버킷 또는 멀티 리전 버킷이어야 합니다.
  • 데이터를 해당 리전의 버킷으로 복사합니다.

한 Cloud Storage 리전에서 다른 리전으로 데이터를 복사할 경우 Cloud Storage 네트워크 가격 책정이 적용됩니다.

데이터 복사 테이블 복사 요금은 청구되지 않지만 새 테이블 및 복사한 테이블을 저장하는 데는 요금이 청구됩니다. 자세한 내용은 기존 테이블 복사를 참조하세요.
데이터 내보내기 BigQuery에서 Cloud Storage로 데이터를 내보낼 때 내보내기 작업에 대한 요금은 청구되지 않지만, Cloud Storage 내 데이터 저장에 대한 요금은 청구됩니다. 자세한 내용은 Cloud Storage 가격 책정 페이지의 데이터 스토리지를 참조하세요. 더 자세한 내용은 BigQuery에서 데이터 내보내기를 참조하세요.
데이터세트 삭제 데이터세트 삭제 요금은 청구되지 않습니다.
테이블, 뷰, 파티션, 함수 삭제 테이블, 뷰, 개별 테이블 파티션 또는 사용자 정의 함수 삭제 요금은 청구되지 않습니다.
메타데이터 작업 list, get, patch, update, delete 호출 요금은 청구되지 않습니다. 그 예로 데이터세트 나열, 데이터세트의 액세스제어 목록 업데이트, 테이블 설명 업데이트 또는 데이터세트의 사용자 정의 함수 나열 등이 있습니다.
유사 열 읽기 다음과 같은 유사 열의 콘텐츠 쿼리에는 요금이 부과되지 않습니다.

_TABLE_SUFFIX - 와일드 카드 테이블을 쿼리하거나 표준 SQL에서 테이블 데코레이터의 시맨틱스를 확보할 때 사용
_PARTITIONDATE - 수집 시간으로 파티션을 나눈 테이블을 쿼리할 때 사용
_PARTITIONTIME - 수집 시간으로 파티션을 나눈 테이블을 쿼리할 때 사용
_FILE_NAME - 외부 데이터 소스에 기반하여 테이블을 쿼리할 때 사용
메타테이블 읽기 다음과 같은 메타 테이블의 콘텐츠 쿼리에는 요금이 부과되지 않습니다.

__PARTITIONS_SUMMARY__ - 파티션을 나눈 테이블 또는 수집 시간으로 파티션을 나눈 테이블에서 파티션에 관한 메타데이터를 가져올 때 사용
__TABLES_SUMMARY__ - 데이터세트에서 테이블 및 뷰에 관한 메타데이터를 가져올 때 사용
UDF 생성, 교체, 호출 현재 영구적인 사용자 정의 함수(UDF)의 생성, 교체, 호출 시에는 요금이 청구되지 않습니다. 영구적 UDF는 현재 베타 버전으로서 가격이 변경될 수 있습니다.

항상 무료 사용 한도

Google Cloud Platform 무료 등급 혜택 중 하나로 BigQuery의 일부 리소스를 특정 한도까지 무료로 사용할 수 있습니다. 무료 사용량은 무료 체험판 기간 및 그 이후에도 사용할 수 있습니다. 그러나 이 사용 한도를 소진하고 무료 체험판 사용 기간이 종료된 경우에는 이 페이지의 가격 정책에 따라 요금이 청구됩니다.

리소스 월별 무료 사용량 한도 세부정보
스토리지 매월 10GB까지는 무료입니다. BigQuery에 저장된 BigQuery ML 모델 및 학습 데이터는 BigQuery 스토리지 무료 등급에 포함됩니다.
쿼리(분석) 매월 처리되는 쿼리 데이터 중 최초 1TB는 무료입니다. BigQuery ML 예측, 검사, 평가 기능을 사용하는 쿼리는 BigQuery 분석 무료 등급에 포함됩니다. CREATE MODEL 문을 포함하는 BigQuery ML 쿼리는 포함되지 않습니다.
월정액 요금을 선호하는 대용량 사용 고객을 위한 BigQuery 정액제도 제공하고 있습니다.
BigQuery ML CREATE MODEL 쿼리 매월 CREATE MODEL 문이 포함된 쿼리로 처리되는 데이터 중 최초 10GB는 무료입니다. BigQuery ML CREATE MODEL 쿼리는 BigQuery 분석 무료 등급에 포함되지 않습니다.

쿼리 가격 책정

쿼리 가격이란 SQL 명령어 및 사용자 정의 함수를 실행하거나 데이터 조작 언어(DML)데이터 정의 언어(DDL) 문을 검증할 때 발생하는 비용입니다.

BigQuery에서는 2가지 가격 모델을 제공합니다.

  • 주문형 가격은 유연하고 효율적입니다. 실행한 쿼리에 해당하는 요금만 부과됩니다.
  • 정액제 가격은 예측 가능하며 일관된 월 단위 비용 방식을 제공합니다.

기본적으로 주문형 가격 모델에 따라 요금이 부과됩니다. 원하는 요구사항을 충족하는 가격 모델을 선택할 수 있습니다. 프로젝트 및 위치별로 두 가격 모델을 혼합해 사용할 수도 있습니다.

주문형 가격 책정

주문형 가격에서는 BigQuery에서 처리된 바이트(읽은 바이트라고도 함) 수라는 한 가지 측정항목만 사용하여 쿼리 요금을 청구합니다. 데이터가 BigQuery에 저장되어 있든 Cloud Storage, Google 드라이브, Cloud Bigtable 등의 외부 데이터 소스에 저장되어 있든 관계없이 처리된 바이트 수에 대한 요금이 청구됩니다. 주문형 가격은 사용량만을 기준으로 합니다.

주문형 쿼리 가격은 다음과 같습니다.

쿼리 요금과 관련하여 다음에 유의하세요.

  • BigQuery는 열 형식 데이터 구조를 사용합니다. 따라서 선택한 열의 총 데이터 처리량을 기준으로 요금이 청구되며, 열별 총 데이터는 해당 열의 데이터 유형에 따라 계산됩니다. 데이터 크기 계산 방식에 대한 자세한 내용은 데이터 크기 계산을 참조하세요.
  • 오류가 발생한 쿼리 또는 캐시에서 결과를 검색하는 쿼리에는 요금이 청구되지 않습니다.
  • 요금은 가장 가까운 MB 단위로 반올림되고, 쿼리가 참조하는 테이블당 최소 데이터 처리량은 10MB이며, 쿼리당 최소 데이터 처리량은 10MB입니다.
  • 실행 중인 쿼리 작업을 취소해도 쿼리가 완전히 실행되었을 경우 전체 비용이 발생할 수 있습니다.
  • 쿼리를 실행하면 결과에 명시적 LIMIT를 설정해도 선택한 열에서 처리된 데이터를 기준으로 요금이 청구됩니다.
  • 테이블 파티션 나누기클러스터링이 쿼리에서 처리되는 데이터 양을 줄이는 데 도움이 될 수 있습니다. 가능한 경우 항상 파티션 나누기 및 클러스터링을 사용하는 것이 좋습니다.
  • Google Cloud Platform SKU 페이지에서는 주문형 쿼리 가격을 분석 가격이라고 지칭합니다.

주문형 쿼리 비용 관리

BigQuery의 비용 관리 메커니즘으로 쿼리 비용을 관리할 수 있습니다. 다음 설정이 가능합니다.

정액제 가격 책정

BigQuery는 데이터 처리량(TB)에 따른 주문형 가격보다 월정액 요금을 선호하는 고객을 위한 정액제를 제공합니다.

정액제에 등록하면 BigQuery 슬롯으로 측정되는 전용 쿼리 처리 용량을 구매하게 됩니다. 모든 바이트 처리 비용이 월정액에 포함됩니다. 쿼리가 정액제 용량을 초과하면 추가 정액제 리소스를 사용할 수 있을 때까지 쿼리가 초과한 용량에 비례하여 느리게 실행됩니다.

정액제 가격 책정:

  • DML 및 DDL 문을 포함한 쿼리 비용에 적용됩니다.
  • 스토리지 비용에는 적용되지 않습니다. 스토리지 비용에 대한 자세한 내용은 스토리지 가격 책정을 참조하세요.
  • 리전 리소스로 구매됩니다. 한 리전에서 구매한 정액제 용량은 다른 리전에서 사용할 수 없습니다.
  • 고객이 Google Cloud Platform 지원팀에 문의하면 프로젝트당 동시 실행 할당량을 늘릴 수 있습니다.
  • 월간 및 연간 약정으로 사용할 수 있습니다.

정액제 가격 책정 세부정보

정액제에 등록할 경우

  • 구매 확인 날짜로부터 30일 동안 월간 약정을 취소하거나 다운그레이드할 수 없습니다.

    첫 30일이 지나면 언제든지 취소하거나 다운그레이드할 수 있습니다. 취소 또는 다운그레이드 시 요금이 월간 요금에 따라 초 단위로 일할 계산됩니다.

    예:

    • 29일째에는 취소할 수 없습니다.
    • 31일째 첫 1초 중에 취소하면 30일 1초에 대한 요금이 청구됩니다.
    • 셋째 달 중간에 취소하면 해당 달의 월간 요금 중 50%가 청구됩니다.
  • 연간 약정은 1년 동안 취소하거나 다운그레이드할 수 없습니다.

    약정을 체결한지 1년이 되기 전에 다음 해에 갱신되도록 선택하거나 해당 연도가 끝난 후 시작되는 월간 정액제로 전환할 수 있습니다. 월간 정액제로 전환한 경우 언제든지 취소 가능하며 월간 요금에 따라 초 단위로 청구됩니다.

    예:

    • 연간 약정 날짜가 지난 후 다음 해에 그대로 갱신하면 새로운 연간 약정이 체결되어 연간 약정 요율에 따라 요금이 계속 청구됩니다.
    • 연간 약정 날짜가 지난 후 다음 해에 갱신하지 않을 경우 언제든지 취소 가능하며 요금이 월간 요금에 따라 초 단위로 일할 계산됩니다.
  • BigQuery 슬롯을 추가로 구매하려면 새 약정을 체결해야 합니다.

  • 정액제는 특정 BigQuery 위치별로 구매합니다.
    정액제를 구매할 때 위치별로 슬롯 할당을 지정하게 됩니다. 여러 위치에서 슬롯을 사용하려면 위치별로 슬롯을 구매해야 합니다.
  • 정액제 및 주문형 가격을 함께 사용할 수 있습니다.
    한 프로젝트에서는 정액제 또는 주문형 가격 중 하나를 사용할 수 있습니다. 특정 위치에 여러 프로젝트가 존재하는 경우 정액제 가격과 주문형 가격을 사용할 프로젝트를 각각 선택할 수 있습니다.
  • 정액제를 중단하려면 약정을 취소하거나 다운그레이드해야 합니다.

월간 정액제 가격 책정

정액제에 등록하면 구매 용량이 BigQuery 슬롯으로 측정됩니다. 다음 표에서는 월간 정액제 구매에 따라 할당되는 슬롯 수를 보여줍니다.

연간 정액제 가격 책정

정액제에 등록하면 구매 용량이 BigQuery 슬롯으로 측정됩니다. 다음 표에서는 연간 정액제 구매에 따라 할당되는 슬롯 수를 보여줍니다. 연간 정액제에 등록해도 요금이 매달 청구됩니다.

월간 및 연간 약정을 통한 슬롯 구매는 현재 알파 버전입니다. 알파 테스트에 참가하려면 이 양식을 작성하세요.

기존 정액제를 고수하는 고객에게는 변경되는 사항이 없습니다. 기존 정액제를 계속 이용하려면 영업 담당자에게 문의하세요.

스토리지 가격 책정

데이터가 BigQuery에 로드되면 저장 요금이 청구됩니다. 스토리지 가격은 압축되지 않은 상태에서 테이블에 저장된 데이터의 양을 기준으로 책정됩니다.

데이터의 크기는 개별 열의 데이터 유형에 따라 계산됩니다. 데이터 크기 계산 방식에 대한 자세한 내용은 데이터 크기 계산을 참조하세요.

활성 스토리지

활성 스토리지 요금은 다음과 같습니다.

스토리지 가격은 초당 MB 단위로 계산됩니다. 예를 들면 다음과 같습니다.

  • 0.5개월 동안 100MB를 저장한 경우 $0.001(0.1¢) 과금
  • 0.5개월 동안 500GB를 저장한 경우 $5 과금
  • 1개월 동안 1TB를 저장한 경우 $20 과금

장기 스토리지

연속으로 90일 동안 테이블을 수정하지 않으면 해당 테이블의 스토리지 가격이 자동으로 약 50% 인하됩니다. 테이블이 장기 스토리지로 간주되더라도 성능, 내구성, 가용성 또는 기타 기능은 저하되지 않습니다.

장기 스토리지 가격은 다음과 같습니다.

테이블을 수정하면 일반 스토리지 가격으로 돌아가며, 90일 타이머가 다시 0부터 계수되기 시작합니다. 다음을 포함해 테이블의 데이터를 수정하는 모든 작업이 타이머를 재설정합니다.

작업 세부정보
테이블에 데이터 로드 대상 테이블에 데이터를 추가하거나 대상 테이블을 덮어쓰는 모든 로드 또는 쿼리 작업
테이블에 데이터 복사 대상 테이블에 데이터를 추가하거나 대상 테이블을 덮어쓰는 모든 복사 작업
테이블에 쿼리 결과 쓰기 대상 테이블에 데이터를 추가하거나 대상 테이블을 덮어쓰는 모든 쿼리 작업
데이터 조작 언어(DML) 사용 DML 문을 사용하여 테이블 데이터 수정
데이터 정의 언어(DDL) 사용 `CREATE OR REPLACE TABLE` DDL 문을 사용하여 테이블 변경
테이블에 데이터 스트리밍 tabledata.insertAll API 호출을 통한 데이터 수집

다음을 포함한 나머지 기타 작업은 타이머를 재설정하지 않습니다.

  • 테이블 쿼리
  • 테이블을 쿼리하는 뷰 만들기
  • 테이블에서 데이터 내보내기
  • 다른 대상 테이블로 테이블 복사
  • 테이블 리소스 패치 또는 업데이트

파티션을 나눈 테이블의 각 파티션은 장기 스토리지 가격 적용 여부가 별도로 고려됩니다. 파티션 중 하나가 90일 동안 수정되지 않았다면 해당 파티션의 데이터가 장기 스토리지로 간주되어 할인 가격을 적용받습니다.

테이블이 결제 주기 중간에 90일 기준에 도달하면 가격은 이에 맞춰 일할 계산됩니다.

장기 스토리지 가격은 Cloud Bigtable, Cloud Storage, Google 드라이브와 같은 외부 데이터 소스에 저장된 데이터가 아닌 BigQuery 스토리지에만 적용됩니다.

BigQuery Storage API 가격 책정

BigQuery Storage API에는 주문형 가격 모델이 적용됩니다. 읽은 데이터에 대한 요금이 부과됩니다. 정액제로 등록한 고객은 BigQuery Storage API를 사용해 무료로 매달 최대 300TB의 데이터를 읽을 수 있습니다. 300TB/월을 초과한 읽기는 주문형 요율에 따라 요금이 청구됩니다.

주문형 가격 책정

주문형 가격에서는 ReadRows 호출을 통해 BigQuery 스토리지에서 읽은 바이트 수를 기준으로 BigQuery Storage API 요금이 부과됩니다.

읽은 바이트 수에는 필터링에 사용된 데이터는 포함되나 ReadRows에서 결과로 반환된 데이터는 포함되지 않습니다. 임시 테이블에서 읽은 데이터에는 요금이 부과되지 않습니다.

주문형 BigQuery Storage API 요금은 다음과 같습니다.

BigQuery Storage API 요금과 관련하여 다음 사항을 참고해 주세요.

  • 읽은 전체 데이터 양에 따라 요금이 청구됩니다. 열당 읽은 전체 데이터는 열의 데이터 유형을 기준으로 계산되며 데이터 크기는 열의 데이터 유형을 기준으로 계산됩니다. 데이터 크기 계산 방식에 대한 자세한 내용은 데이터 크기 계산을 참조하세요.
  • ReadRows 호출이 실패해도 읽기 세션에 읽은 데이터의 요금이 부과됩니다.
  • 스트림 끝에 도달하기 전에 ReadRows 호출을 취소하면 취소 전에 읽은 데이터의 요금이 부과됩니다. ReadRows 호출을 취소하기 전에 읽었으나 반환되지 않은 데이터가 요금에 포함될 수 있습니다.
  • 가능한 경우 파티션을 나누고 클러스터링된 테이블을 사용하는 것이 좋습니다. WHERE 절을 사용해 파티션을 프루닝하면 읽은 데이터 양을 줄일 수 있습니다. 자세한 내용은 파티션을 나눈 테이블 쿼리를 참조하세요.

데이터 크기 계산

BigQuery에 데이터를 로드하거나 데이터를 쿼리하면 데이터 크기를 기준으로 요금이 청구됩니다. 데이터 크기는 각 열의 데이터 유형 크기에 따라 계산됩니다.

저장된 데이터의 크기와 쿼리로 처리된 데이터의 크기는 GB(기가바이트, 1GB = 230바이트) 단위로 계산됩니다. 이 측정 단위를 GiB(기비바이트)라고도 합니다. 1TB는 240바이트(1,024GB)입니다.

BigQuery의 데이터 유형별 크기는 다음과 같습니다.

데이터 유형 크기
INT64/INTEGER 8바이트
FLOAT64/FLOAT 8바이트
NUMERIC 16바이트
BOOL/BOOLEAN 1바이트
STRING 2바이트 + UTF-8 인코딩 문자열 크기
BYTES 2바이트 + 값의 바이트 수
DATE 8바이트
DATETIME 8바이트
TIME 8바이트
TIMESTAMP 8바이트
STRUCT/RECORD 0바이트 + 포함된 필드 크기
GEOGRAPHY 16바이트 + 24바이트 * 위치 유형의 꼭짓점 수(ST_NumPoints 함수를 사용하면 꼭짓점 수를 확인할 수 있음)

모든 데이터 유형에서 Null 값은 0바이트로 계산됩니다.

반복되는 열은 배열로 저장되며 값의 수를 기준으로 크기가 계산됩니다. 예를 들어 정수 열(INT64)이 반복(ARRAY<INT64>)되고 항목이 4개 포함되어 있으면 32바이트(항목 4개 x 8바이트)로 계산됩니다.

스트리밍 가격 책정

BigQuery에 데이터를 로드하는 작업은 무료이지만, 스트리밍 데이터에는 예외적으로 소액의 요금이 부과됩니다.

스트리밍 삽입의 가격은 다음과 같습니다.

데이터 조작 언어 가격 책정

BigQuery는 쿼리에서 처리한 바이트 수에 따라 DML 쿼리에 요금을 부과합니다.

파티션을 나누지 않은 테이블의 DML 가격 책정

파티션을 나누지 않은 테이블의 경우 처리된 바이트 수는 다음과 같이 계산됩니다.

DML 문 처리한 바이트
INSERT 쿼리로 스캔한 테이블에서 참조한 모든 열에 대해 처리한 바이트의 합계입니다.
UPDATE 쿼리로 스캔한 테이블에서 참조한 모든 열에 있는 바이트의 합계
+ UPDATE 시작 시점에 업데이트된 테이블의 모든 열에 대한 바이트의 합계입니다.
DELETE 쿼리로 스캔한 테이블에서 참조한 모든 열에 있는 바이트의 합계
+ DELETE 시작 시점에 수정된 테이블의 모든 열에 대한 바이트의 합계입니다.
MERGE MERGE 문에 INSERT 절만 있다면 쿼리로 스캔한 테이블에서 참조한 모든 열의 처리된 바이트의 합계에 대한 비용이 청구됩니다.
MERGE 문에 UPDATE 또는 DELETE 절이 있으면 쿼리로 스캔한 소스 테이블에서 참조한 모든 열의 처리된 바이트의 합계
+ MERGE 시작 시점에 대상 테이블의 모든 열의 바이트 합계에 대한 비용이 청구됩니다.

파티션을 나눈 테이블의 DML 가격 책정

파티션을 나눈 테이블의 경우 처리된 바이트 수는 다음과 같이 계산됩니다.

DML 문 처리한 바이트
INSERT 쿼리로 스캔한 모든 파티션에서 참조한 모든 열에 대해 처리한 바이트의 합계입니다.
UPDATE 쿼리로 스캔한 테이블의 모든 파티션에서 참조한 모든 열에 대해 처리한 바이트의 합계
+ UPDATE 시작 시점에 업데이트된 테이블에서 업데이트 또는 스캔된 파티션의 모든 열에 대한 바이트의 합계입니다
DELETE 쿼리로 스캔한 테이블의 모든 파티션에서 참조한 모든 열에 대해 처리한 바이트의 합계
+ DELETE 시작 시점에 수정 중인 테이블에서 수정 또는 스캔된 파티션의 모든 열에 대한 바이트의 합계입니다.
MERGE MERGE 문에 INSERT 절만 있다면 쿼리로 스캔한 모든 파티션에서 참조한 모든 열의 처리된 바이트의 합계에 대한 비용이 청구됩니다.
MERGE 문에 UPDATE 또는 DELETE 절이 있으면 쿼리로 스캔한 소스 테이블의 모든 파티션에서 참조한 모든 열에 대해 처리된 바이트의 합계
+ MERGE 시작 시점에 대상 테이블에서 업데이트, 삭제, 스캔한 파티션의 모든 열에 대한 바이트의 합계에 대한 비용이 청구됩니다.

데이터 정의 언어 가격 책정

BigQuery는 쿼리에서 처리한 바이트 수에 따라 DDL 쿼리에 요금이 부과됩니다. DDL 문에 대해 처리된 바이트 수는 다음과 같이 계산됩니다.

DDL 문 처리한 바이트
CREATE TABLE 없음
CREATE TABLE ... AS SELECT ... 쿼리로 스캔한 테이블에서 참조한 모든 열에 대해 처리한 바이트의 합계입니다.
CREATE VIEW 없음
DROP TABLE 없음
DROP VIEW 없음

클러스터링된 테이블 가격 책정

BigQuery에서 클러스터링된 테이블을 만들고 사용할 때 부과되는 요금은 데이터를 대상으로 실행하는 쿼리와 테이블에 저장된 데이터의 양에 따라 결정됩니다. 클러스터링된 테이블을 사용하면 데이터를 프루닝해 쿼리로 데이터가 처리되지 않도록 하여 쿼리 비용을 절감할 수 있습니다. 이 프로세스는 블록 프루닝이라고 합니다.

블록 프루닝

BigQuery는 클러스터링 열의 값에 따라 클러스터링된 테이블의 데이터를 정렬하고 블록으로 정리합니다.

클러스터링된 열의 필터를 포함한 쿼리를 제출하는 경우 BigQuery는 클러스터링 정보를 사용해 블록에 쿼리와 관련된 데이터가 포함되어 있는지 효율적으로 판단합니다. BigQuery는 이러한 방식으로 관련 블록만 스캔하며, 이 프로세스를 블록 프루닝이라고 합니다.

쿼리 가격은 처리한 바이트 수를 기준으로 합니다. 클러스터링된 열의 필터를 포함한 쿼리를 클러스터링된 테이블에 실행하는 경우, BigQuery는 필터 표현식과 블록 메타데이터를 사용해 쿼리로 스캔된 블록을 프루닝합니다.

블록이 프루닝되면 스캔되지 않습니다. 스캔된 블록만이 쿼리로 처리된 데이터의 바이트를 계산하는 데 사용됩니다. 클러스터링된 테이블에 대한 쿼리로 처리되는 바이트 수는 스캔된 블록에서 쿼리에 참조된 각 열에서 읽은 바이트 수의 총 합계와 동일합니다.

클러스터링된 테이블이 여러 필터를 사용하는 쿼리에서 여러 번 참조되는 경우, BigQuery는 필터마다 적절한 블록의 열 스캔 작업에 대해 요금을 청구합니다.

스크립팅 가격 책정

스크립트를 실행하기 전까지는 일반적으로 스크립트에서 스캔되는 바이트 수를 알 수 없으므로, BigQuery팀에서는 의도하지 않은 쿼리 비용이 발생하지 않도록 BigQuery 스크립팅 베타 기간에는 정액제 예약으로 프로젝트를 사용할 것을 권장합니다. 또는 BigQuery 샌드박스를 사용해 제한된 무료 스크립트 실행을 활용할 수도 있습니다. 추후 BigQuery팀이 스크립트에서 스캔되는 총 바이트 수에 대한 보다 명시적인 제어 및 스크립트 내 개별 문을 제공할 예정입니다. 베타 출시 버전이므로 가격 업데이트는 BigQuery 출시 노트를 참조하세요.

스크립트가 실패할 경우 실패 전까지 발생한 모든 문 비용이 적용됩니다. 실패한 문에 대해서는 비용이 발생하지 않습니다.

SELECT, INSERT, UPDATE 등 공개 출시된 문 유형의 경우 문을 실행하는 비용은 공개 가격 책정 문서에서 설명하고 있습니다. 스크립팅에 특정한 문 유형에는 다음 가격이 적용됩니다.

  • DECLARE: DEFAULT 표현식이 참조한 모든 테이블에서 스캔된 바이트의 합계에 대해 요금이 부과됩니다. 테이블 참조가 없는 DECLARE 문은 비용이 발생하지 않습니다.
  • SET: 표현식이 참조한 모든 테이블에서 스캔한 바이트의 합계에 대해 요금이 부과됩니다. 테이블 참조가 없는 SET 문은 비용이 발생하지 않습니다.
  • IF: 조건 표현식이 참조한 모든 테이블에서 스캔한 바이트의 합계에 대해 요금이 부과됩니다. 테이블 참조가 없는 IF 조건 표현식은 비용이 발생하지 않습니다. 실행되지 않은 IF 블록의 문에 대해서도 비용이 발생하지 않습니다.
  • WHILE: 조건 표현식이 참조한 모든 테이블에서 스캔한 바이트의 합계에 대해 요금이 부과됩니다. 테이블 참조가 없는 WHILE 문은 비용이 발생하지 않습니다. 실행되지 않은 WHILE 블록의 문에 대해서도 비용이 발생하지 않습니다.
  • CONTINUE/ITERATE: 관련 비용이 없습니다.
  • BREAK/LEAVE: 관련 비용이 없습니다.
  • BEGIN/END: 관련 비용이 없습니다.

임시 테이블의 경우 스크립트 실행 기간의 스토리지 요금이 부과되지 않습니다. 하지만 문을 생성, 수정 또는 쿼리하는 일반적인 비용은 발생합니다.

BigQuery 가격 책정 예시

쿼리 비용 추정

쿼리 가격의 예시는 쿼리 비용 추정을 참조하세요.

스토리지 비용 추정

스토리지 가격의 예시는 스토리지 비용 추정을 참조하세요.

파티션을 나누지 않은 테이블의 DML 가격 예시

다음 예시는 BigQuery가 파티션을 나누지 않은 테이블을 수정하는 DML 문의 바이트를 어떻게 계산하는지 보여줍니다.

예시 1: 파티션을 나누지 않은 테이블 UPDATE

table1INTEGER 유형의 col1STRING 유형의 col2 열이 2개 있습니다.

UPDATE table1 SET col1 = 1 WHERE col2 = 2;

이 예시에서 처리한 바이트 =

  • col1 내 총 바이트 수 +
  • col2 내 총 바이트 수

예시 2: 파티션을 나누지 않은 테이블 UPDATE

table1INTEGER 유형의 col1STRING 유형의 col2 열이 2개 있습니다. table2INTEGER 유형의 field1 열이 1개 있습니다.

UPDATE table1 SET col1 = 1 WHERE col1 in (SELECT field1 from table2)

이 예시에서 처리한 바이트 =

  • UPDATEtable1.col1 내 총 바이트 수 +
  • UPDATEtable1.col2 내 총 바이트 수 +
  • table2.field1 내 총 바이트 수

파티션을 나눈 테이블의 DML 가격 예시

다음 예시는 BigQuery가 파티션을 나눈 테이블과 수집 시간을 수정하는 DML 문의 바이트를 어떻게 계산하는지 보여줍니다. 예시에서 사용된 테이블의 JSON 스키마 표현을 확인하려면 'DML 문을 사용하여 파티션을 나눈 테이블 데이터 업데이트' 페이지의 예시에서 사용한 테이블을 참조하세요.

예시 1: 수집 시간으로 파티션을 나눈 테이블 INSERT

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mytableINTEGER 유형의 field1STRING 유형의 field2 열이 2개 있습니다.

INSERT INTO mytable (_PARTITIONTIME, field1) AS SELECT TIMESTAMP(DATE(ts)), id from mytable2

이 예시에서 처리한 바이트 =

  • mytable2.ts 내 총 바이트 수 +
  • mytable2.id 내 총 바이트 수

행이 삽입된 mytable 테이블의 크기는 쿼리 비용에 영향을 주지 않습니다.

예시 2: 파티션을 나눈 테이블 INSERT

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mycolumntableINTEGER 유형의 field1, STRING 유형의 field2, BOOLEAN 유형의 field3TIMESTAMP 유형의 ts 열이 4개 있습니다.

INSERT INTO mycolumntable (ts, field1) AS SELECT ts, id from mytable2

이 예시에서 처리한 바이트 =

  • mytable2.ts 내 총 바이트 수 +
  • mytable2.id 내 총 바이트 수

행이 삽입된 mycolumntable 테이블의 크기는 쿼리 비용에 영향을 주지 않습니다.

예시 3: 수집 시간으로 파티션을 나눈 테이블 UPDATE

DML 문 1: 단일 파티션 업데이트

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mytableINTEGER 유형의 field1STRING 유형의 field2 열이 2개 있습니다.

UPDATE project.mydataset.mytable T SET T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

이 예시에서 처리한 바이트 =

  • mytable2.id 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mytable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mytable.field2 내 총 바이트 수

DML 문 2: 테이블의 다른 파티션을 기반으로 파티션 업데이트

UPDATE project.mydataset.mytable T SET T._PARTITIONTIME = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT 1 from project.mydataset.mytable S WHERE S.field1 = T.field1 AND S._PARTITIONTIME = TIMESTAMP("2017-06-01") )

이 예시에서 처리한 바이트 =

  • "2017-05-01" 파티션의 mytable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mytable.field2 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mytable.field1 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mytable.field2 내 총 바이트 수

이 경우 UPDATE 문의 비용은 "2017-05-01" 및 "2017-06-01"에 해당하는 파티션의 모든 필드 크기의 합계입니다.

예시 4: 파티션을 나눈 테이블 UPDATE

DML 문 1: 단일 파티션 업데이트

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mycolumntableINTEGER 유형의 field1, STRING 유형의 field2, BOOLEAN 유형의 field3TIMESTAMP 유형의 ts 열이 4개 있습니다.

UPDATE project.mydataset.mycolumntable T SET T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

이 예시에서 처리한 바이트 =

  • mytable2.id 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field2 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field3 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.ts 내 총 바이트 수

DML 문 2: 테이블의 다른 파티션을 기반으로 파티션 업데이트

UPDATE project.mydataset.mycolumntable T SET T.ts = TIMESTAMP(“2017-06-01”), T.field1 = T.field1 + 100 WHERE DATE(T.ts) = “2017-05-01” AND EXISTS (SELECT 1 from project.mydataset.mycolumntable S WHERE S.field1 = T.field1 AND DATE(S.ts) = "2017-06-01")

이 예시에서 처리한 바이트 =

  • "2017-05-01" 파티션의 mycolumntable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field2 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field3 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.ts 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mycolumntable.field1 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mycolumntable.field2 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mycolumntable.field3 내 총 바이트 수 +
  • "2017-06-01" 파티션의 mycolumntable.ts 내 총 바이트 수

이 경우 UPDATE 문의 비용은 "2017-05-01" 및 "2017-06-01"에 해당하는 파티션의 모든 필드 크기의 합계입니다.

예시 5: 수집 시간으로 파티션을 나눈 테이블 DELETE

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mytableINTEGER 유형의 field1STRING 유형의 field2 열이 2개 있습니다.

DELETE project.mydataset.mytable T WHERE T._PARTITIONTIME = TIMESTAMP(“2017-05-01”) AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

이 예시에서 처리한 바이트 =

  • mytable2.id 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mytable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mytable.field2 내 총 바이트 수

예시 6: 파티션을 나눈 테이블 DELETE

mytable2INTEGER 유형의 idTIMESTAMP 유형의 ts 열이 2개 있습니다. mycolumntableINTEGER 유형의 field1, STRING 유형의 field2, BOOLEAN 유형의 field3TIMESTAMP 유형의 ts 열이 4개 있습니다.

DELETE project.mydataset.mycolumntable T WHERE DATE(T.ts) =“2017-05-01” AND EXISTS (SELECT S.id from project.mydataset.mytable2 S WHERE S.id = T.field1)

이 예시에서 처리한 바이트 =

  • mytable2.id 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field1 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field2 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.field3 내 총 바이트 수 +
  • "2017-05-01" 파티션의 mycolumntable.ts 내 총 바이트 수

클러스터링된 테이블 가격 책정 예시

이름이 ClusteredSalesData인 클러스터링 테이블이 있습니다. 이 테이블은 timestamp 열로 파티션을 나누고 customer_id 열로 클러스터링됩니다. 데이터는 다음 블록 세트로 정리됩니다.

파티션 식별자 블록 ID 블록의 customer_id 최솟값 블록의 customer_id 최댓값
20160501 B1 10000 19999
20160501 B2 20000 24999
20160502 B3 15000 17999
20160501 B4 22000 27999

다음 쿼리를 테이블에 실행합니다. 쿼리에는 customer_id 열의 필터가 포함되어 있습니다.

SELECT
  SUM(totalSale)
FROM
  `mydataset.ClusteredSalesData`
WHERE
  customer_id BETWEEN 20000
  AND 23000
  AND DATE(timestamp) = "2016-05-01"

이 쿼리는 다음과 같은 작업을 합니다.

  • 블록 B2와 B4에서 timestamp, customer_id, totalSale 열을 스캔합니다.
  • timestamp 파티션을 나눈 열의 DATE(timestamp) = "2016-05-01" 필터 조건자로 인해 B3 블록을 프루닝합니다.
  • customer_id 클러스터링 열의 customer_id BETWEEN 20000 AND 23000 필터 조건자로 인해 B1 블록을 프루닝합니다.

스크립팅 가격 책정 예시

다음 예시의 스크립트에는 문에서 발생하는 비용을 설명하는 주석이 문 위에 포함되어 있습니다.

-- No cost, since no tables are referenced.
DECLARE x DATE DEFAULT CURRENT_DATE();
-- Incurs the cost of scanning string_col from dataset.table.
DECLARE y STRING DEFAULT (SELECT MAX(string_col) FROM dataset.table);
-- Incurs the cost of copying the data from dataset.big_table.  Once the
-- table is created, you are not charged for storage while the rest of the
-- script runs.
CREATE TEMP TABLE t AS SELECT * FROM dataset.big_table;
-- Incurs the cost of scanning column1 from temporary table t.
SELECT column1 FROM t;
-- No cost, since y = 'foo' doesn't reference a table.
IF y = 'foo' THEN
  -- Incurs the cost of scanning all columns from dataset.other_table, if
  -- y was equal to 'foo', or otherwise no cost since it is not executed.
  SELECT * FROM dataset.other_table;
ELSE
  -- Incurs the cost of scanning all columns from dataset.different_table, if
  -- y was not equal to 'foo', or otherwise no cost since it is not executed.
  UPDATE dataset.different_table
  SET col = 10
  WHERE true;
END IF;
-- Incurs the cost of scanning date_col from dataset.table for each
-- iteration of the loop.
WHILE x < (SELECT MIN(date_col) FROM dataset.table) DO
  -- No cost, since the expression does not reference any tables.
  SET x = DATE_ADD(x, INTERVAL 1 DAY);
  -- No cost, since the expression does not reference any tables.
  IF true THEN
    -- LEAVE has no associated cost.
    LEAVE;
  END IF;
  -- Never executed, since the IF branch is always taken, so does not incur
  -- a cost.
  SELECT * FROM dataset.big_table;
END WHILE;
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

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