MariaDB에 대한 데이터 가져오기 고려 사항 - Amazon Relational Database Service

MariaDB에 대한 데이터 가져오기 고려 사항

다음 내용에는 MariaDB로 데이터를 로드하는 것과 관련된 기술 정보가 포함되어 있습니다. 이 콘텐츠는 MariaDB 서버 아키텍처에 익숙한 사용자를 대상으로 합니다.

이진 로깅

이진 로깅을 활성화하면 로깅을 비활성화했을 때와 비교해 데이터 로드 성능이 저하되고 최대 4배의 추가 디스크 공간이 필요합니다. 데이터를 로드하는 데 사용되는 트랜잭션 크기는 시스템 성능 및 디스크 공간 요구 사항에 직접적인 영향을 미칩니다. 트랜잭션이 클수록 더 많은 리소스가 필요합니다.

트랜잭션 크기

트랜잭션 크기는 MariaDB 데이터 로드의 다음 측면에 영향을 미칩니다.

  • 리소스 소비

  • 디스크 공간 사용률

  • 프로세스 재개

  • 복구 시간

  • 입력 형식(플랫 파일 또는 SQL)

이 섹션에서는 트랜잭션 크기가 이진 로깅에 미치는 영향을 설명하고 큰 데이터를 로드하는 중에 이진 로깅을 비활성화하는 이유를 논증합니다. Amazon RDS 자동 백업 보존 기간을 설정하여 이진 로깅을 활성화 및 비활성화할 수 있습니다. 0이 아닌 값으로 설정하면 이진 로깅이 활성화되고 0으로 설정하면 비활성화됩니다. 자세한 내용은 백업 보관 기간 섹션을 참조하세요.

이 섹션에서는 대규모 트랜잭션이 InnoDB에 미치는 영향과 트랜잭션 크기를 작게 유지하는 것이 중요한 이유도 설명합니다.

작은 트랜잭션

작은 트랜잭션의 경우, 이진 로깅을 사용하면 데이터 로드에 필요한 디스크 쓰기 작업 수가 배가됩니다. 이 결과 다른 데이터베이스 세션의 성능이 심각하게 저하되고 데이터 로딩 시간이 증가할 수 있습니다. 발생하는 성능 저하는 부분적으로 다음 요인에 따라 달라집니다.

  • 업로드 속도

  • 로드 중에 발생하는 기타 데이터베이스 활동

  • Amazon RDS DB 인스턴스의 용량

또한, 이진 로그는 로그가 백업 및 제거될 때까지 로드된 데이터의 양과 대략적으로 같은 양의 디스크 공간을 사용합니다. Amazon RDS는 이진 로그를 자주 백업하고 제거하는 방법으로 이 문제를 최소화합니다.

대규모 트랜잭션

대규모 트랜잭션의 경우 다음과 같은 이유로 이진 로깅이 사용하는 IOPS 및 디스크가 3배로 늘어납니다.

  • 이진 로그 캐시는 트랜잭션 데이터를 일시적으로 디스크에 저장합니다.

  • 이 캐시는 디스크 공간을 소비하는 트랜잭션 크기에 따라 증가합니다.

  • 트랜잭션(커밋 또는 롤백)이 완료되면 시스템은 캐시를 이진 로그에 복사합니다.

이 프로세스는 다음과 같은 데이터 복사본 세 개를 만듭니다.

  • 원본 데이터

  • 디스크의 캐시

  • 최종 이진 로그 항목

각 쓰기 작업에는 추가 IO가 발생하여 성능에 더욱 영향을 미칩니다.

따라서 이진 로깅에는 로깅을 비활성화했을 때에 비해 디스크 공간이 3배 필요합니다. 예를 들어 10GiB의 데이터를 단일 트랜잭션으로 로드하면 다음과 같은 세 개의 복사본이 만들어집니다.

  • 테이블 데이터 10GiB

  • 이진 로그 캐시 10GiB

  • 이진 로그 파일 10GiB

필요한 총 임시 디스크 공간은 30GiB입니다.

중요한 디스크 공간 고려 사항:

  • 캐시 파일은 세션이 종료되거나 새 트랜잭션이 다른 캐시를 만들 때까지 유지됩니다.

  • 이진 로그는 백업될 때까지 유지되며, 잠재적으로 20GiB(캐시 및 로그)를 장기간 차지할 수 있습니다.

LOAD DATA LOCAL INFILE을 사용하여 데이터를 로드하는 경우 데이터 복구는 로드 전에 수행된 백업에서 데이터베이스를 복구해야 하는 경우를 대비하여 네 번째 복사본을 만듭니다. 복원 중에 MariaDB가 이진 로그에서 플랫 파일로 데이터를 추출합니다. 그런 다음 MariaDB는 LOAD DATA LOCAL INFILE을 실행합니다. 이전 예시의 내용을 바탕으로 봤을 때, 이 복구를 수행하려면 테이블, 캐시, 로그 및 로컬 파일에 대해 각각 10GiB씩 총 40GiB의 임시 디스크 공간이 필요합니다. 최소 40GiB의 여유 디스크 공간이 없으면 복구가 실패합니다.

대규모 데이터 로드 최적화

대규모 데이터 로드의 경우 이진 로깅을 비활성화하여 오버헤드 및 디스크 공간 요구 사항을 줄입니다. 백업 보존 기간을 0으로 설정하여 이진 로깅을 비활성화할 수 있습니다. 로드가 완료되면 백업 보존 기간을 0이 아닌 적절한 값으로 복원합니다. 자세한 정보는 Amazon RDS DB 인스턴스 수정 및 설정 표의 백업 보존 기간을 참조하세요.

참고

DB 인스턴스가 읽기 전용 복제본의 원본 DB 인스턴스인 경우에는 백업 보존 기간을 0으로 설정할 수 없습니다.

데이터를 로드하기 전에 DB 스냅샷을 만드는 것이 좋습니다. 자세한 내용은 수동 백업 관리 섹션을 참조하세요.

InnoDB

실행 취소 로깅 및 복구 옵션에 대한 다음 정보는 데이터베이스 성능을 최적화하기 위해 InnoDB 트랜잭션을 작게 유지하는 데 도움이 됩니다.

InnoDB 실행 취소 로깅 이해

실행 취소는 트랜잭션 롤백을 활성화하고 다중 버전 동시성 제어(MVCC)를 지원하는 로깅 메커니즘입니다.

MariaDB 10.11 이하 버전의 경우 실행 취소 로그는 InnoDB 시스템 테이블스페이스(일반적으로 ibdata1)에 저장되며 제거 스레드가 로그를 제거할 때까지 유지됩니다. 따라서 대규모 데이터 로드 트랜잭션은 시스템 테이블스페이스가 상당히 커지는 원인이 될 수 있고, 이때 사용되는 디스크 공간은 데이터베이스를 다시 만들어야 회수할 수 있습니다.

모든 MariaDB 버전에서 제거 스레드는 가장 오래된 활성 트랜잭션이 커밋되거나 롤백될 때까지 실행 취소 로그를 제거할 수 없습니다. 데이터베이스가 로드 중에 다른 트랜잭션을 처리 중인 경우, 이들 트랜잭션의 실행 취소 로그 역시 누적되며 트랜잭션이 커밋되고 MVCC에 대해 실행 취소 로그가 필요한 다른 트랜잭션이 없더라도 실행 취소 로그를 제거할 수 없습니다. 이 경우 읽기 전용 트랜잭션을 포함한 모든 트랜잭션이 느려집니다. 이 속도 저하는 로드 트랜잭션뿐만 아니라 모든 트랜잭션이 변경하는 모든 행에 모든 트랜잭션이 액세스하기 때문에 발생합니다. 실제로 트랜잭션은 장기 실행 로드 트랜잭션으로 인해 실행 취소 로그 정리 중에 제거되지 않는 실행 취소 로그를 검사해야 합니다. 이는 수정된 행에 액세스하는 모든 작업의 성능에 영향을 줍니다.

InnoDB 트랜잭션 복구 옵션

InnoDB는 커밋 작업을 최적화하지만 대규모 트랜잭션 롤백은 느립니다. 더 빠른 복구를 위해 시점 복구를 수행하거나 DB 스냅샷을 복원합니다. 자세한 내용은 시점 복구DB 인스턴스 복원(을)를 참조하세요.

데이터 가져오기 형식

MariaDB는 플랫 파일과 SQL이라는 두 가지 데이터 가져오기 형식을 지원합니다. 각 형식에 대한 정보를 검토하여 요구 사항에 가장 적합한 옵션을 결정합니다.

플랫 파일

소규모 트랜잭션의 경우 LOAD DATA LOCAL INFILE을 사용하여 플랫 파일을 로드합니다. 이 데이터 가져오기 형식은 SQL 사용에 비해 다음과 같은 이점을 제공할 수 있습니다.

  • 더 낮은 네트워크 트래픽

  • 데이터 전송 비용 절감

  • 데이터베이스 처리 오버헤드 감소

  • 더 빠른 처리

LOAD DATA LOCAL INFILE은 전체 플랫 파일을 하나의 트랜잭션으로 로드합니다. 다음과 같은 이점을 위해 개별 파일의 크기를 작게 유지합니다.

  • 재개 기능 – 로드된 파일을 추적할 수 있습니다. 로드 중에 문제가 발생하면 중단된 부분부터 다시 시작할 수 있습니다. 일부 데이터를 Amazon RDS로 다시 전송해야 할 수도 있지만, 파일이 작으면 재전송되는 양이 최소화됩니다.

  • 병렬 데이터 로드 - 단일 파일 로드에 충분한 IOPS와 네트워크 대역폭이 있는 경우 병렬로 로드하면 시간이 절약될 수 있습니다.

  • 로드 속도 제어 - 데이터 로드가 다른 프로세스에 부정적인 영향을 미치는 경우 파일 간 간격을 늘려 로드 속도를 제어할 수 있습니다.

대규모 트랜잭션은 LOAD DATA LOCAL INFILE을 사용하여 데이터를 가져올 때의 이점을 줄입니다. 대량의 데이터를 더 작은 파일로 나눌 수 없는 경우 SQL을 사용하는 것을 고려하세요.

SQL

SQL은 플랫 파일에 비해 한 가지 중요한 장점이 있는데, 그것은 바로 트랜잭션 크기를 작게 유지하기 쉽다는 점입니다. 그러나 SQL은 플랫 파일보다 로드하는 데 훨씬 더 오래 걸릴 수 있습니다. 또한 장애 발생 후 재개 위치를 결정하기 어려울 수 있으며, mariadb-dump 파일을 다시 시작할 수 없습니다. mariadb-dump 파일을 로드하는 동안 오류가 발생하는 경우 이 파일을 수정하거나 바꾸어야 로드를 재개할 수 있습니다. 또는 장애의 원인을 수정한 후 파일을 로드하고 재전송하기 전의 특정 시점으로 복원할 수 있습니다. 자세한 내용은 시점 복구 섹션을 참조하세요.

데이터베이스 체크포인트에 Amazon RDS DB 스냅샷 사용

이진 로깅 없이 몇 시간 또는 며칠 등의 긴 기간 동안 데이터를 로드하는 경우 DB 스냅샷을 사용하여 데이터 안전을 위한 주기적 체크포인트를 제공하세요. 각 DB 스냅샷은 시스템 장애 또는 데이터 손상 이벤트 중에 복구 시점 역할을 하는 데이터베이스 인스턴스의 일관된 사본을 만듭니다. DB 스냅샷은 빠르기 때문에 체크포인트를 자주 제공해도 로드 성능에 미치는 영향이 최소화됩니다. 데이터베이스 내구성이나 복구 기능에 영향을 주지 않고 이전 DB 스냅샷을 삭제할 수 있습니다. DB 스냅샷에 대한 자세한 내용은 수동 백업 관리 섹션을 참조하세요.

데이터베이스 로드 시간 단축

다음 항목은 로드 시간을 줄이기 위한 추가 팁입니다.

  • MariaDB 데이터베이스로 데이터를 로드하기 전에 모든 보조 인덱스를 만듭니다. 다른 데이터베이스 시스템과 달리 MariaDB는 보조 인덱스를 추가하거나 수정할 때 전체 테이블을 다시 빌드합니다. 이 프로세스는 인덱스 변경 사항이 있는 새 테이블을 만들고, 모든 데이터를 복사하고, 원본 테이블을 삭제합니다.

  • 프라이머리 키 순서로 데이터를 로드합니다. InnoDB 테이블의 경우 이렇게 하면 로드 시간을 75%~80% 줄이고 데이터 파일 크기를 50% 줄일 수 있습니다.

  • foreign_key_checks0으로 설정하여 외래 키 제약 조건을 비활성화합니다. LOAD DATA LOCAL INFILE을 통해 로드되는 플랫 파일의 경우 이 단계는 많은 경우에 필수입니다. 모든 로드에서 외래 키 검사를 비활성화하면 데이터 로드가 가속화됩니다. 로드가 완료된 후 foreign_key_checks1로 설정하고 데이터를 확인하여 제약 조건을 다시 활성화합니다.

  • 리소스 한도가 가까워지지 않은 한 데이터를 병렬로 로드합니다. 여러 테이블 세그먼트에서 동시 로드를 활성화하기 위해 적절한 경우 파티셔닝된 테이블을 사용합니다.

  • SQL 실행 오버헤드를 줄이려면 여러 INSERT 문을 단일 다중 값 INSERT 작업으로 결합합니다.mariadb-dump는 이 최적화를 자동으로 구현합니다.

  • innodb_flush_log_at_trx_commit0으로 설정하여 InnoDB 로그 IO 작업을 줄입니다. 로드가 완료되면 innodb_flush_log_at_trx_commit1로 복원합니다.

    주의

    innodb_flush_log_at_trx_commit0으로 설정하면 InnoDB가 커밋이 발생할 때마다가 아닌 1초마다 로그를 플러시합니다. 이 설정은 성능을 높이지만 시스템 장애 발생 시 트랜잭션이 손실될 위험이 있습니다.

  • 읽기 전용 복제본이 없는 DB 인스턴스로 데이터를 로드하는 경우 sync_binlog0으로 설정합니다. 로드가 완료되면 sync_binlog parameter1로 복원합니다.

  • DB 인스턴스를 다중 AZ 배포로 변환하기 전에 단일 AZ DB 인스턴스로 데이터를 로드합니다. DB 인스턴스가 이미 다중 AZ 배포를 사용하는 경우 데이터 로드를 위해 단일 AZ 배포로 전환하지 않는 것이 좋습니다. 이렇게 해도 아주 작은 부분만이 개선됩니다.