기계 번역으로 제공되는 번역입니다. 제공된 번역과 원본 영어의 내용이 상충하는 경우에는 영어 버전이 우선합니다.

쓰기 워크로드 조정

로드 밸런싱을 구현하고 라이터 인스턴스를 비우면 쓰기 작업량이 급증할 때 쓰기 워크로드 성능을 높일 수 있습니다. 동시 실행 빈도가 높을 때 쓰기 성능을 높이려면 다음 추가 단계를 따르세요.

애플리케이션 계층으로 참조 무결성 이동

참조 무결성 검사가 중요하긴 하지만 하이퍼스케일링을 사용하면 부하에 악영향을 미칠 수 있습니다. 각 쓰기에 대해 쓰기 자체를 실행하기 전에 추가 스캔을 수행해야 하므로 성능이 저하됩니다. 애플리케이션에 엄격한 무결성 검사가 필요한 경우 애플리케이션 계층에 빌드하여 쓰기 시 병목 현상이 발생하지 않도록 합니다.

무거운 프라이머리 키 사용 안 함

프라이머리 키는 가볍게 유지하세요. InnoDB 스토리지 엔진은 테이블에 생성하는 다른 모든 인덱스에 프라이머리 키를 추가합니다. 프라이머리 키가 크면 인덱스 크기에 영향을 줍니다. 프라이머리 키가 상당히 크면 데이터 페이지 저장 및 검색 속도가 느려집니다. 일반적인 예로는 범용 고유 식별자를 프라이머리 키로 사용하는 경우를 들 수 있습니다. 하이퍼스케일 환경에서 성능을 목표로 하는 경우에는 좋은 방법이 아닙니다.

파티션 교환을 사용하여 파티션된 테이블에 데이터를 로드할 수 있습니다.

파티션된 테이블에 대규모 데이터 세트를 쓰는 경우 삽입을 위해 기본 테이블에 액세스하지 않기 때문에 LOAD DATA FROM S3와 파티션 교환을 결합하면 성능이 향상될 수 있습니다. 파티션 교환에는 데이터 정의 언어(DDL)가 포함되며, 이로 인해 테이블에 메타데이터가 잠깁니다. 파티션 교환 DDL이 대기 없이 메타데이터 잠금을 확보할 수 있도록 테이블에서 실행되는 쿼리가 거의 없거나 전혀 없을 때 이 작업을 수행해야 합니다. 교환 자체를 완료하는 데 몇 밀리초 밖에 걸리지 않습니다.

사용되지 않는 인덱스 삭제

InnoDB는 데이터 증가에 따라 쿼리 계획을 최적화하므로 데이터베이스에서 사용하지 않는 인덱스가 있는지 확인하고 제거하는 것이 좋습니다. 애플리케이션이 데이터를 테이블에 쓸 때 사용하지 않는 인덱스는 IO를 소모합니다. 사용하지 않는 인덱스 목록을 확인하고 이러한 인덱스가 분기별 보고서와 같은 드문 상황에서 사용되는 인덱스가 아닌지 확인하세요. 또한 일부 인덱스은 고유성 또는 순서 지정을 적용하는 데 사용되므로 반드시 고려해야 합니다.

이전 행 버전을 효율적으로 제거해야 합니다.

MVCC(다중 버전 동시성 제어)의 InnoDB 구현에서는 레코드가 수정되면 수정 중인 데이터의 현재(이전) 버전이 먼저 실행 취소 로그에 실행 취소 레코드로 기록됩니다. 기록 목록 길이(HLL) 값이 커지면 InnoDB 가비지 수집 스레드(제거 스레드)가 쓰기 워크로드를 따라가지 못하거나 장기 실행 쿼리 또는 트랜잭션으로 인해 제거가 차단되는 것입니다. 가비지 수집이 차단되거나 지연되면 데이터베이스에서 상당한 제거 지연이 발생하여 쿼리 성능에 부정적인 영향을 미칠 수 있습니다. 다음 권장 사항을 사용하여 제거 프로세스를 최적화할 수 있습니다.

로깅으로 인해 추가 경합이 발생하지 않는지 확인

일반 쿼리 로그에는 클라이언트 연결 및 연결 해제뿐만 아니라 서버에서 수신한 모든 명령문이 받은 순서대로 기록됩니다. 활성화되면 로깅이 동기식으로 이루어지므로 사용량이 많은 시스템에서 성능이 크게 저하될 수 있습니다. 필요한 경우가 아니면 일반 로그를 비활성화하는 것이 좋습니다.

느린 쿼리 로그는 long_query_time 실행 시간(기본 설정 10초)보다 오래 걸린 명령문을 기록합니다. 이 설정을 0으로 설정하면 모든 명령문이 동기적으로 로깅되므로 사용량이 많은 데이터베이스에서는 성능이 저하될 수 있습니다.