Transaction의 역할
Transaction은 일반적으로 데이터의 정합성을 유지하기 위해 사용한다.
DB와 connection을 맺고 데이터를 처리하는 작업이 완료되지 않고 중단되었을 경우 해당 작업을 roll-back 시키는 단위를 설정함으로써 데이터가 정합성을 유지하게 해준다.
Transaction Log로 인한 성능 저하
MySQL InnoDB 엔진에는 중단된 Transaction을 roll-back 시키기 위해서 또는 여러 개의 Transaction을 동시에 사용하기 위해서 변경되기 이전의 데이터를 남기기 위한 undo logs가 존재한다. 이러한 undo logs를 InnoDB에서는 History List라고 부른다.
이러한 log는 트랜잭션이 커밋되기 전까지 계속해서 쌓이는데, Transaction의 크기가 매우 커서 log의 길이가 너무 길어지게 되면 전반적인 Database의 성능이 매우 낮아지게 된다.
낮아지는 이유는 이렇게 log를 쌓는 과정에서 Disk와의 I/O가 빈번하게 일어나며, 이렇게 쌓인 log들을 한번에 purge하는 과정에서 CPU에 지나치게 많은 부하를 줄 수 있기 때문이다.
실제로, DBA 팀에서 메트릭을 통해 이러한 Transaction Log의 상태를 모니터링하고 지나치게 커졌을 시 각 도메인 팀에게 원인 분석 요청을 보낸다.
적절한 Batch 단위를 활용한 성능 향상
이렇게 지나치게 높아진 HLL의 원인은 대부분 지나치게 길게 실행되는 트랜잭션이다. 이러한 트랜잭션은 대규모 데이터의 처리로 인해 발생한다. 따라서 이를 해결하기 위한 가장 간단한 해결 방법은 트랜잭션의 단위를 더 잘게 나누어 커밋이 빈번하게 이루어지게 함으로써 Log의 길이를 줄이는 것이다.
그러나 이렇게 커밋 단위를 작게 가져가는 것에 대한 Trade Off가 존재한다. 성능이 저하된다는 것이다. 수만건 이상의 row를 처리하는 작업은 매건 트랜잭션을 분리하고 커밋을 할 시에 성능이 4~5배 이상으로 저하된다.
따라서 이런 경우에는 특정 단위로 Transaction을 묶어 한번에 처리하는 게 좋을 수 있다.
HLL을 지나치게 키우지 않으면서, 빈번한 Commit으로 인한 성능 저하가 발생하지 않도록 적절한 Batch 단위를 찾아야 한다.
출처
https://d2.naver.com/helloworld/407507
https://blog.doosikbae.com/130
