일괄 로드 권장사항

이 페이지에서는 대용량 데이터를 Cloud Spanner에 효율적으로 일괄 로드하기 위한 가이드라인을 설명합니다.

다음과 같은 여러 가지 방법으로 데이터를 Cloud Spanner에 일괄 로드할 수 있습니다.

일괄 로드 성능 가이드라인

다음 가이드라인을 따르면 최적의 일괄 로드 성능을 얻을 수 있습니다.

  • 각 쓰기 트랜잭션과 관련된 분할 수를 최소화합니다. 트랜잭션에서 분할 수가 적을수록 쓰기 처리량이 극대화되므로 성능이 극대화됩니다.

  • 파티션 나누기를 최대한 사용하여 작업자 태스크 전체에서 파티션 쓰기를 분배합니다.

Cloud Spanner는 부하 기반 분할을 사용하여 노드 전체에서 데이터 부하를 균등하게 분배합니다. 몇 분간 부하가 높으면 Cloud Spanner는 인터리브 처리되지 않은 테이블의 행 사이에 분할 경계를 적용합니다. 일반적으로 데이터 부하가 잘 분산되어 있고 스키마 설계 및 일괄 로드 권장사항을 따르면 인스턴스에서 사용 가능한 CPU 리소스가 포화될 때까지 쓰기 처리량은 몇 분마다 두 배씩 증가합니다.

기본 키로 데이터 파티션 나누기

일괄 로드 쓰기 처리량을 최적화하려면 다음 패턴을 사용하여 기본 키로 데이터 파티션을 나눕니다.

  • 각 파티션에는 키 열에 지정된 연속 행 범위가 있습니다.
  • 각 커밋에는 단일 파티션의 데이터만 있습니다.

파티션 수는 Cloud Spanner 인스턴스에 있는 노드 수의 10배가 되도록 하는 것이 좋습니다. 행을 파티션에 할당하려면 다음을 수행합니다.

  • 기본 키로 데이터를 정렬합니다.
  • 데이터를 10 * (노드 수)개의 크기가 동일한 개별 파티션으로 나눕니다.
  • 개별 작업자 태스크를 만들어 각 파티션에 할당합니다. 애플리케이션에서 작업자 태스크를 만들 수 있으나 Cloud Spanner에서는 만들 수 없습니다.

이 패턴을 따르면 대용량 부하의 전체 일괄 쓰기 처리량은 노드당 최대 10~20MB/초가 됩니다.

데이터를 로드하면 Cloud Spanner는 분할을 만들고 업데이트하여 인스턴스의 노드 부하를 분산합니다. 이 프로세스 중에 처리량이 일시적으로 감소할 수 있습니다.

노드가 3개 있는 리전 구성이 있습니다. 인터리브 처리되지 않은 테이블에 행이 90,000개 있습니다. 테이블의 기본 키 범위는 1~90000입니다.

  • 행: 90,000개 행
  • 노드: 3
  • 파티션: 10 * 3 = 30개
  • 파티션당 행 수: 90000 / 30 = 3000개

첫 번째 파티션의 키 범위는 1~3000입니다. 두 번째 파티션의 키 범위는 3001~6000입니다. 30번째 파티션의 키 범위는 87001~90000입니다. (대형 테이블에 순차 키를 사용해서는 안 됩니다. 이 예는 데모용입니다.)

각 작업자 태스크는 단일 파티션의 쓰기를 보냅니다. 각 파티션 내에서는 기본 키를 기준으로 행을 순차적으로 써야 합니다. 또한 기본 키를 기준으로 임의로 행을 쓰면 합당하게 높은 처리량이 제공됩니다. 측정 테스트를 실행하면 데이터세트에 최고의 성능을 제공하는 방법을 확인할 수 있습니다.

파티션을 사용하지 않기로 결정한 경우

각 변형이 단일 행을 삽입하는 커밋에서 임의의 행 쓰기가 한 번에 행을 하나씩 쓰는 것보다 느릴 수 있습니다. 임의의 각 행이 다른 분할에 속하여 여러 분할이 관련될 수 있습니다. 최악의 경우 각 쓰기에 Cloud Spanner 인스턴스의 모든 분할이 관련될 수 있습니다. 위에서 언급한 대로 쓰기에 분할이 많이 관련될수록 쓰기 처리량은 줄어듭니다.

푸시백 방지

Cloud Spanner에서 처리할 수 있는 요청보다 더 많은 쓰기 요청을 보낼 수 있습니다. 이러한 경우 Cloud Spanner는 트랜잭션을 취소하여 과부하를 처리하며, 이를 푸시백이라고 합니다. 쓰기 전용 트랜잭션에서는 Cloud Spanner가 자동으로 트랜잭션을 다시 시도합니다. 이 경우 푸시백으로 인해 지연 시간이 증가합니다. 부하가 높으면 푸시백이 최대 1분까지 지속될 수 있습니다. 부하가 심각하게 높으면 푸시백이 몇 분 동안 지속될 수 있습니다. 푸시백을 방지하려면 쓰기 요청을 제한하여 CPU 사용률을 적당한 한도 이내로 유지시켜야 합니다.

한 번에 1~5MB의 변형 커밋

쓰기 양에 관계없이 Cloud Spanner에 대한 각 쓰기는 약간의 오버헤드가 있습니다. 처리량을 극대화하려면 쓰기당 저장되는 데이터 양을 극대화합니다. 쓰기 용량이 커질수록 쓰기당 오버헤드 비율이 낮아집니다. 각 커밋에 수백 개의 행을 변형하는 것이 좋습니다. 일반적으로 용량이 상대적으로 큰 행을 쓰는 경우 커밋 크기가 1~5MB일 때 최고의 성능이 발휘됩니다. 작은 값이나 색인이 생성된 값을 쓸 때는 일반적으로 단일 커밋에서 최대 수백 개의 행을 쓰는 것이 가장 좋습니다. 커밋 크기 및 행 수와는 별개로 커밋당 변형 수는 20,000개로 제한됩니다. 최적의 성능을 확인하려면 처리량을 테스트하고 측정해야 합니다.

커밋 크기가 5MB보다 크거나 행이 수백 개 이상이면 추가 이점이 없으며, 커밋 크기 및 커밋당 변형 수에 대한 Cloud Spanner 제한을 초과할 수 있습니다.

보조 색인 가이드라인

데이터베이스에 보조 색인이 있으면 테이블 데이터를 로드하기 전/후 중에서 데이터베이스 스키마에 색인을 추가할 시기를 선택해야 합니다.

  • 데이터가 로드되기 전에 색인을 추가하면 스키마 변경을 즉시 완료할 수 있습니다. 그러나 색인 업데이트도 필요하기 때문에 색인에 영향을 주는 각 쓰기 작업이 더 오래 걸립니다. 데이터 로드가 완료되면 배치된 모든 색인에 데이터베이스가 즉시 사용 가능하게 됩니다. 테이블과 테이블 색인을 동시에 만들려면 새 테이블과 새 색인에 대한 DDL 문을 Cloud Spanner에 단일 요청으로 전송합니다.

  • 데이터 로드 후 색인을 추가하면 각 쓰기가 효율적으로 처리됩니다. 하지만 각 색인 백필에 대한 스키마 변경에 시간이 오래 걸릴 수 있습니다. 모든 스키마 변경이 완료되기 전에는 데이터베이스가 완전히 사용 가능한 상태가 아닙니다.

기본적으로 데이터베이스에 포함된 색인이 40개 미만이면 데이터 로드 후 색인을 추가합니다. 데이터베이스의 색인이 40개를 초과하면 데이터를 로드하기 전에 색인을 추가합니다.

처리량 테스트 및 측정

처리량을 예측하기 어려울 수 있습니다. 최종 로드를 실행하기 전에 일괄 로드 계획을 테스트하는 것이 좋습니다. 파티션 나누기 및 성능 모니터링을 사용하는 자세한 예는 데이터 부하 처리량 극대화를 참조하세요.

기존 데이터베이스에 정기적으로 일괄 로드할 때의 권장사항

데이터는 있지만 보조 색인이 없는 기존 데이터베이스를 업데이트할 때에는 다음과 같은 권장사항도 적용됩니다.

보조 색인이 있는 경우에도 이 안내를 따르면 합당한 성능을 얻을 수 있습니다. 성능은 트랜잭션에서 평균적으로 얼마나 많은 분할이 관련되는지에 따라 달라집니다. 처리량이 너무 감소하면 다음을 시도해 보세요.

  • 각 커밋에 포함된 변형 수를 줄이면 처리량이 증가할 수 있습니다.
  • 업로드 크기가 업데이트 중인 테이블의 현재 전체 크기보다 큰 경우, 보조 색인을 삭제하고 데이터를 업로드한 후 보조 색인을 다시 추가합니다. 일반적으로 이 단계는 필요하지 않지만 처리량을 향상시킬 수 있습니다.

Avro 파일을 가져올 때의 권장사항

다음 페이지에서는 Avro 파일 가져오기 성능 향상과 관련된 정보를 제공합니다.

Dataflow 커넥터 사용 권장사항

Dataflow 커넥터 사용 시의 성능 팁은 Cloud Spanner에 쓰기 및 데이터 변환을 참조하세요.