24) DBMS 활용 (배치 처리 주의사항)

대용량 작업

• 개발자 생각
  • 최대한 굵고 짧게
  • 동시에 많은 스레드로 빠르게 처리 완료
  • 중요한 쿼리들이 실행되지 못할 수 도 있다.
• DBA 생각
  • 가능한 가볍게 ( 가능한 짧게 )
  • 소수의 쓰레드로 최소의 DBMS자원 소모

 

dbms서버는 공유자원

• 특정 서비스에서 과도한 자원 점유시, 다른 서비스의 처리 지연 유발
• 때로는 다른 서비스의 쿼리실패 & 장애 유발
• DBMS 서버의 처리 용량은 다양하다. 이에 맞는 동시성 제어가 필요하다.

 

Long Transaction

• Idle Transaction
  • auto_commit = OFF 상태 또는 명시적 트랜잭션 (Begin Transaction) 사용시에
  • Begin 이후 또는 쿼리 실행 이후 대기 상태로 남은 트랜잭션 (Commit , Rollback 실행 전)
• Active long transaction
  • auto_commit 모드 무관하게
  • 오랜 시간 동안 실행되는 쿼리를 실행중인 트랜잭션
• MySQL 아키텍처
  • Non locking consistent read기능은 MVCC를 활용하여 구현한다.
  • MVCC는 undo log를 활용하고 이는 일정 시간 이전은 purge 되어야한다.
• Undo log의 부작용
  • 오래된 트랜잭션은 오래 전의 undo log를 purge하지 못하도록 한다.
  • undo log가 많이 쌓이면 , 많은 메모리 및 Disk Read/Write를 초래한다.
  • 자원 사용률이 높아지고 , 쿼리 성능이 저하된다.
    
    
    
• MySQL Community version
  • Long Transactino이 실행되는 해당 서버에만 영향을 미침
  • 복제되는 서버에서는 Long Transaction 영향도 없음
  • Replica 에서는 Long Transaction으로 인한 서비스 악영향이 적을 수 있다.
• Aurora MySQL
  • Long Transaction이 실행되는 해당 서버뿐만 아니라 해당 서버의 Writer 서버까지 LT효과가 확장됨
  • Read Replica 에서 장시간 실행되는 트랜잭션으로 인한 문제 발생이 가능하다.
  • 공유 스토리지 사용해서 read, write가 논리적으로 연결이 되어있기 때문에 문제가 되는것이다.