SQL 안티패턴 방지

다음 권장사항에서는 BigQuery의 성능에 영향을 주는 쿼리 안티패턴을 방지하기 위한 지침을 제공합니다.

자체 조인

권장사항: 가급적 자체 조인을 사용하지 마세요. 대신 윈도우 함수를 사용하세요.

일반적으로 자체 조인은 행 종속 관계를 계산하는 데 사용됩니다. 자체 조인을 사용하면 출력 행의 수가 두 배가 될 수 있습니다. 이렇게 출력 데이터가 늘어나면 성능이 저하될 수 있습니다.

따라서 쿼리에서 생성되는 추가 바이트의 수를 줄이려면 자체 조인을 사용하는 대신 윈도우(분석) 함수를 사용해야 합니다.

데이터 편향

권장사항: 쿼리에서 처리하는 키가 일부 값으로 과도하게 편향된 경우에는 가능한 한 일찍 데이터를 필터링하세요.

파티션 편향(데이터 편향이라고도 함)은 데이터가 매우 균등하지 않은 크기의 파티션으로 분할된 경우를 가리킵니다. 이 경우 슬롯 간에 전송되는 데이터 양에 불균형이 발생합니다. 슬롯 간에 파티션을 공유할 수 없으므로 한 파티션이 특히 크면 과도하게 큰 파티션을 처리하는 슬롯이 느려지거나 비정상적으로 종료될 수 있습니다.

파티션 키에 다른 값보다 자주 발생하는 값이 있으면 파티션이 커집니다. 예를 들어 guest 또는 NULL에 대한 항목이 많은 user_id 필드를 기준으로 그룹화하는 경우가 이에 해당합니다.

슬롯의 리소스가 오버로드되면 resources exceeded 오류가 발생합니다. 슬롯의 무작위 섞기 제한(메모리 압축 시 2TB)에 도달하면 무작위 섞기가 디스크에 기록되어 성능에 추가적인 영향을 미칩니다. 고정 요금제를 이용하는 고객이라면 할당된 슬롯 수를 늘릴 수 있습니다.

쿼리 설명 계획을 조사한 결과 평균 계산 시간과 최대 계산 시간 사이의 큰 차이가 확인된 경우 데이터가 편향되었을 수 있습니다.

데이터 편향으로 인한 성능 문제를 방지하려면 다음과 같이 하세요.

  • APPROX_TOP_COUNT와 같은 적절한 집계 함수를 사용하여 데이터가 편향되었는지 확인합니다.
  • 데이터를 가능한 한 일찍 필터링합니다.

불균형 조인

JOIN 절을 사용할 때도 데이터 편향이 나타날 수 있습니다. BigQuery는 조인의 양쪽에서 데이터를 무작위로 섞으므로 조인 키가 동일한 모든 데이터가 동일한 샤드에 속하게 됩니다. 이 무작위 섞기로 인해 슬롯이 오버로드될 수 있습니다.

불균형 조인과 연관된 성능 문제를 방지하려면 다음과 같이 하세요.

  • 테이블의 행을 불균형 키로 사전 필터링합니다.
  • 가능하면 쿼리를 두 개의 쿼리로 나눕니다.

교차 조인(카티전 곱)

권장사항: 입력보다 더 많은 출력을 생성하는 조인은 가급적 사용하지 마세요. CROSS JOIN이 필요하면 데이터를 사전에 집계하세요.

교차 조인은 첫 번째 테이블의 각 행이 두 번째 테이블의 모든 행에 조인되는 쿼리입니다 (양쪽에 고유하지 않은 키가 있음). 최악의 경우 출력은 왼쪽 테이블의 행 수에 오른쪽 테이블의 행 수를 곱한 만큼이 됩니다. 극단적인 경우에는 쿼리가 완료되지 않을 수 있습니다.

쿼리 작업이 완료되면 쿼리 계획 설명에 출력 행과 입력 행이 표시됩니다. JOIN 절의 양쪽 행 수를 조인 키를 기준으로 그룹화하여 출력하도록 쿼리를 수정하면 카티전 프로덕트를 확인할 수 있습니다.

입력보다 더 많은 출력을 생성하는 조인과 연관된 성능 문제를 방지하려면 다음과 같이 하세요.

  • GROUP BY 절을 사용하여 데이터를 사전에 집계합니다.
  • 윈도우 함수를 사용합니다. 때로는 윈도우 함수가 교차 조인보다 더 효율적입니다. 자세한 내용은 분석 함수를 참조하세요.

단일 행을 업데이트 또는 삽입하는 DML 문

권장사항: 특정 데이터 요소에 대한 DML 문(한 번에 1개의 행 업데이트 또는 삽입)은 가급적 사용하지 마세요. 일괄 업데이트 및 삽입을 수행하세요.

특정 데이터 요소에 대한 DML 문을 사용하는 것은 BigQuery를 온라인 트랜잭션 처리(OLTP) 시스템처럼 취급하는 것입니다. BigQuery는 데이터 요소 조회가 아니라 테이블 검색을 사용한 온라인 분석 처리(OLAP)에 초점을 맞추고 있습니다. OLTP 같은 동작(단일 행 또는 삽입)이 필요한 경우에는 Cloud SQL과 같이 OLTP 사용 사례를 지원하도록 설계된 데이터베이스를 사용하는 것이 좋습니다.

BigQuery DML 문은 일괄 업데이트를 위한 것입니다. BigQuery의 UPDATEDELETE DML 문은 단일 행 변형이 아니라 정기적인 데이터 재작성을 중심으로 합니다. INSERT DML 문은 일부 예외적인 경우에 사용하기 위한 것입니다. 삽입 시 로드 작업과 동일한 수정 할당량을 소비하게 됩니다. 사용 사례에 빈번한 단일 행 삽입이 필요한 경우에는 데이터를 삽입하는 대신 스트리밍하는 것이 좋습니다.

여러 개의 UPDATE 문을 일괄 처리하여 매우 긴 쿼리에서 많은 튜플이 생성되면 쿼리 길이 제한인 256KB에 도달할 수 있습니다. 쿼리 길이 제한을 해결하려면 일련의 직접적인 튜플 대체 대신 논리적 기준을 기반으로 업데이트를 처리할 수 있는지 여부를 고려해야 합니다.

예를 들어 대체 레코드 세트를 다른 테이블에 로드한 후, 해당 열이 원본 테이블의 업데이트되지 않은 열과 일치할 경우 원본 테이블의 모든 값을 업데이트하는 DML 문을 작성할 수 있습니다. 예를 들어 원본 데이터가 t 테이블에 있고 업데이트가 u 테이블에 스테이징된 경우 쿼리는 다음과 같습니다.

UPDATE
  dataset.t t
SET
  my_column = u.my_column
FROM
  dataset.u u
WHERE
  t.my_key = u.my_key
이 페이지가 도움이 되었나요? 평가를 부탁드립니다.

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

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