DML(Data Manipulation Language)으로 데이터 변환

GoogleSQL은 Google 표준 SQL의 새로운 이름입니다! 이름은 달라졌지만 여전히 유용한 SQL 언어입니다.

BigQuery DML을 사용하면 BigQuery 테이블에서 데이터를 업데이트, 삽입, 삭제할 수 있습니다.

다음 조건에 따라 SELECT 문을 실행할 때와 같은 방식으로 DML 문을 실행할 수 있습니다.

• GoogleSQL을 사용해야 합니다. GoogleSQL을 사용 설정하려면 SQL 언어 전환을 참조하세요.
• 쿼리의 대상 테이블을 지정할 수 없습니다.

BigQuery DML 문 목록과 사용 방법에 대한 예시는 GoogleSQL의 DML 문을 참조하세요. DML 문이 처리한 바이트 수를 계산하는 방법에 관한 자세한 내용은 주문형 쿼리 크기 계산을 참고하세요.

동시 작업

BigQuery는 테이블의 행을 추가, 수정 또는 삭제하는 DML 문의 동시 실행을 관리합니다.

참고: DML 문에는 최대 테이블 쓰기 속도와 같은 비율 제한이 적용됩니다. 테이블에 대해 작업을 한 번에 많은 수로 제출하면 비율 제한에 도달할 수 있습니다. 이러한 비율은 실행 가능한 DML 문의 총 수를 제한하지 않습니다. 비율 제한을 초과했다는 오류 메시지가 표시되면 재시도 사이에 지수 백오프를 사용하여 작업을 재시도하세요.

INSERT DML 동시 실행

INSERT 문 첫 1500개가 제출된 후 24시간 동안 즉시 실행됩니다. 이 한도에 도달하면 테이블에 쓰는 INSERT 문의 동시 실행이 10개로 제한됩니다. 추가 INSERT 문이 PENDING 큐에 추가됩니다. 특정 시점에 테이블에 대해 INSERT 문을 최대 100개까지 큐에 추가할 수 있습니다. INSERT 문이 완료되면 다음 INSERT 문이 큐에서 삭제되고 실행됩니다.

DML INSERT 문을 더 자주 실행해야 하는 경우 Storage Write API를 사용하여 데이터를 테이블로 스트리밍하는 것이 좋습니다.

UPDATE, DELETE, MERGE DML 동시 실행

UPDATE, DELETE, MERGE DML 문을 변형 DML 문이라고 합니다. 다른 변형 DML 작업을 실행 중이거나 대기 중인 경우 테이블에 있는 변형 DML 문을 한 개 이상 제출하는 경우 BigQuery는 최대 2개까지 동시 실행하며 최대 20개까지 PENDING 상태로 큐에 추가될 수 있습니다. 이전에 실행 중인 작업이 완료되면 다음 대기 중 작업이 큐에서 제거되고 실행됩니다. 큐에 추가된 변형 DML 문은 최대 길이가 20인 테이블별 큐를 공유합니다. 각 테이블의 최대 큐 길이를 초과한 추가 문은 실패하고 오류 메시지 Resources exceeded during query execution: Too many DML statements outstanding against table PROJECT_ID:TABLE, limit is 20.이 표시됩니다.

6시간 넘게 큐에 추가된 대화형 우선순위 DML 작업이 실패하고 다음 오류 메시지가 표시됩니다.

DML statement has been queued for too long

DML 문 충돌

테이블에서 동시에 실행되는 DML 문을 변형하면 DML 문이 동일한 파티션을 변형하려고 할 때 DML 문이 충돌합니다. 문이 동일한 파티션을 수정하지 않는 한 성공합니다. BigQuery는 실패한 문을 최대 3회까지 재실행을 시도합니다.

• 테이블에 행을 삽입하는 INSERT DML 문은 동시에 실행되는 다른 DML 문과 충돌하지 않습니다.

• MERGE DML 문이 행만 삽입하고 기존 행을 삭제하거나 업데이트하지 않는 한, 이 문은 동시에 실행되는 다른 DML 문과 충돌하지 않습니다. 여기에는 UPDATE 또는 DELETE 절이 있는 MERGE 문을 포함될 수 있습니다(쿼리가 실행될 때 해당 절이 호출되지 않는 한).

세분화된 DML

미리보기

이 기능에는 서비스별 약관의 일반 서비스 약관 섹션에 있는 'GA 이전 제공 서비스 약관'이 적용됩니다. Cloud 데이터 처리 추가 조항에 설명된 대로 이 기능에 대한 개인 정보는 Google Cloud 액세스에 관한 계약에 설명된 의무와 제한사항에 따라 처리할 수 있습니다. GA 이전 기능은 '있는 그대로' 제공되며 지원이 제한될 수 있습니다. 자세한 내용은 출시 단계 설명을 참조하세요.

참고: 이 기능에 대해 의견을 제공하거나 지원을 요청하려면 [e-mail]으로 이메일을 보내세요.

세분화된 DML은 UPDATE, DELETE, MERGE 문 (변형 DML 문이라고도 함)의 실행을 최적화하도록 설계된 성능 개선입니다. 세분화된 DML을 사용 설정하지 않으면 변형이 파일 그룹 수준에서 실행되므로 비효율적인 데이터 재작성이 발생할 수 있습니다. 세분화된 DML은 재작성해야 하는 데이터의 양을 줄이고 전체 슬롯 소비를 줄이는 것을 목표로 하는 더 세분화된 접근 방식을 도입합니다.

세분화된 DML 미리보기에 프로젝트를 등록하는 데 관심이 있는 경우 BigQuery 세분화된 DML 등록 양식을 작성하세요. 프로젝트는 워크로드 평가를 기반으로 선택적으로 등록됩니다.

세분화된 DML 사용 설정

세분화된 DML을 사용 설정하려면 CREATE TABLE 또는 ALTER TABLE DDL 문을 실행할 때 enable_fine_grained_mutations 테이블 옵션을 TRUE로 설정합니다.

세분화된 DML로 새 테이블을 만들려면 CREATE TABLE 문을 사용하세요.

CREATE TABLE mydataset.mytable (
  product STRING,
  inventory INT64)
OPTIONS(enable_fine_grained_mutations = TRUE);

세분화된 DML로 기존 테이블을 변경하려면 ALTER TABLE 문을 사용합니다.

ALTER TABLE mydataset.mytable
SET OPTIONS(enable_fine_grained_mutations = TRUE);

enable_fine_grained_mutations 옵션이 TRUE로 설정되면 변형 DML 문은 세분화된 DML 기능이 사용 설정된 상태로 실행되며 기존 DML 문 구문을 사용합니다.

테이블에서 세분화된 DML을 사용 중지하려면 ALTER TABLE DDL 문을 사용하여 enable_fine_grained_mutations를 FALSE로 설정합니다.

가격 책정

테이블에 세분화된 DML을 사용 설정하면 세분화된 DML 작업과 연결된 추가 변형 메타데이터를 저장하기 위한 추가 BigQuery 스토리지 비용이 발생할 수 있습니다. 실제 비용은 수정되는 데이터의 양에 따라 다르지만 대부분의 경우 테이블 자체의 크기에 비해 무시할 수 있을 것으로 예상됩니다.

reservations을 사용하도록 구성된 프로젝트는 슬롯을 사용하여 테이블 또는 변형 메타데이터의 백그라운드 처리를 비롯한 세분화된 DML 문을 처리합니다.

삭제된 데이터 고려사항

세분화된 DML 작업은 삭제된 데이터를 오프라인 방식으로 처리합니다.

BACKGROUND 할당 프로세스 없이 세분화된 DML 작업을 실행하는 프로젝트는 주문형 가격 책정을 사용하여 데이터를 삭제합니다. 이 경우 삭제된 데이터 처리는 내부 BigQuery 리소스를 사용하여 정기적으로 실행됩니다.

BACKGROUND 할당으로 세분화된 DML 작업을 실행하는 프로젝트는 슬롯을 사용하여 삭제된 데이터를 처리하며 구성된 예약의 리소스 가용성에 영향을 받습니다. 구성된 예약 내에 사용 가능한 리소스가 충분하지 않으면 삭제된 데이터를 처리하는 데 예상보다 오래 걸릴 수 있습니다.

제한사항

세분화된 DML로 사용 설정된 테이블에는 다음과 같은 제한사항이 적용됩니다.

• 세분화된 DML이 사용 설정된 테이블에서 콘텐츠를 읽으려면 tabledata.list 메서드를 사용할 수 없습니다. 대신 Storage Read API를 사용하여 API를 통해 테이블 레코드를 읽습니다.
• 세분화된 DML이 사용 설정된 테이블의 테이블 스냅샷 또는 테이블 클론을 만들 수 없습니다.
• 복제된 데이터 세트의 테이블에서 세분화된 DML을 사용 설정할 수 없으며, 세분화된 DML이 사용 설정된 테이블이 포함된 데이터 세트를 복제할 수 없습니다.
• 멀티 문 트랜잭션에서 실행되는 DML 문은 세분화된 DML로 최적화되지 않습니다.

권장사항

최상의 성능을 위해 다음 패턴을 사용하는 것이 좋습니다.

• 개별 행 업데이트 또는 삽입을 다수로 제출하지 마십시오. 대신 가능한 경우 DML 작업을 함께 그룹화합니다. 자세한 내용은 단일 행을 업데이트 또는 삽입하는 DML 문을 참조하세요.

• 업데이트 또는 삭제 작업이 일반적으로 이전 데이터에서 또는 특정 날짜 범위 내에서 수행되는 경우 테이블의 파티션 나누기를 고려하세요. 파티션 나누기는 변경사항이 테이블 내의 특정 파티션으로 제한되도록 보장합니다.

• 각 파티션의 데이터 양이 적고 각 업데이트가 파티션의 상당 부분을 수정하는 경우 파티션 나누기를 피하세요.

• 하나 이상의 열이 좁은 값 범위 내에 있는 행을 자주 업데이트하는 경우 클러스터링된 테이블을 사용하는 것이 좋습니다. 클러스터링은 변경사항을 특정 블록 세트로 제한하여 읽고 써야 하는 데이터 양을 줄입니다. 다음은 열 값의 범위를 필터링하는 UPDATE 문의 예시입니다.

  UPDATE mydataset.mytable
  SET string_col = 'some string'
  WHERE id BETWEEN 54 AND 75;

  다음은 소량의 열 값 목록을 필터링하는 유사한 예시입니다.

  UPDATE mydataset.mytable
  SET string_col = 'some string'
  WHERE id IN (54, 57, 60);

  이러한 경우에는 id 열의 클러스터링을 고려하세요.

• OLTP 기능이 필요한 경우 BigQuery에서 Cloud SQL에 있는 데이터를 쿼리할 수 있는 Cloud SQL 통합 쿼리를 사용하는 것이 좋습니다.

쿼리 성능을 최적화할 수 있는 권장사항은 쿼리 성능 최적화 소개를 참조하세요.

제한사항

• 각 DML 문은 암시적 트랜잭션을 시작합니다. 즉, 각 DML 문이 성공적으로 종료될 때마다 문에서 발생한 변경사항이 자동으로 커밋됩니다.

• tabledata.insertall 스트리밍 메서드를 사용하여 최근에 작성한 행은 UPDATE, DELETE, MERGE 또는 TRUNCATE 문 같은 DML(Data Manipulation Language)을 사용하여 수정할 수 없습니다. 최근 쓰기 작업이란 최근 30분 내에 발생한 작업입니다. 테이블에 있는 다른 모든 행은 UPDATE, DELETE, MERGE 또는 TRUNCATE 문을 통해 수정 가능한 상태로 유지됩니다. 스트리밍된 데이터를 복사 작업에 사용할 수 있게 될 때까지 최대 90분이 소요될 수 있습니다.

  또는 최근에 Storage Write API를 사용하여 작성한 행은 UPDATE, DELETE 또는 MERGE 문을 사용하여 수정할 수 있습니다. 자세한 내용은 최근 스트리밍된 데이터에 DML 사용을 참조하세요.

• when_clause, search_condition, merge_update_clause, merge_insert_clause 내의 상관 서브 쿼리는 MERGE 문에 지원되지 않습니다.

• DML 문을 포함하는 쿼리는 와일드 카드 테이블을 쿼리 대상으로 사용할 수 없습니다. 예를 들어 와일드 카드 테이블은 UPDATE 쿼리의 FROM 절에서 사용할 수 있지만 와일드 카드 테이블을 UPDATE 작업의 대상으로 사용할 수는 없습니다.

다음 단계

• DML 구문 정보와 샘플은 DML 구문을 참조하세요.
• 예약된 쿼리에서 DML 문을 사용하는 방법은 쿼리 예약을 참조하세요.