Transaction

트랜잭션을 지원하지 않는 MyISAM과 트랜잭션을 지원하는 InnoDB 처리 방식에는 무슨 차이가 있을까.

MySQL에서의 트랜잭션

트랜잭션은 반드시 여러 개의 변경 작업을 수행하는 쿼리가 조합됐을 때만 의미 있는 개념은 아니다.

트랜잭션은 하나의 논리적인 작업 셋에 쿼리가 하나가 있든 두 개가 넘든 관계없이 논리적인 작업 셋 자체가 100% 적용되거나(commit) 아무것도 적용되지 않아야 함을 보장해 주는 것이다.

가장 먼저 2개의 insert 쿼리를 수행하여 테이블을 세팅한다. 그다음 각 테이블 fdpk 컬럼에 1, 2, 3을 삽입하는 쿼리를 수행하고 select로 결과를 살펴보자.

insert into table mysiam (fdpk) values (3);
insert into table innodb (fdpk) values (3);

insert into table mysiam (fdpk) values (1), (2), (3);
ERROR 1062: Duplicate entry '3' for key 'PRIMARY'
insert into table innodb (fdpk) values (1), (2), (3);
ERROR 1062: Duplicate entry '3' for key 'PRIMARY'

select * from mysaim;
=> fdpk: 1, 2, 3

select * from innodb
=> fdpk: 3

MyISAM 테이블에는 오류가 발생했음에도 ‘1’, ‘2’는 insert가 되었다. 하지만 InnoDB는 쿼리에서 일부라도 오류가 발생하면 원칙대로 쿼리를 실행하기 전 상태로 복구한다.

MyISAM 테이블에서 발생하는 이러한 현상을 부분 업데이트(Partial Update)라고 표현하고 이 현상은 데이터의 정합성을 맞추는 데 상당히 어렵게 한다.

주의사항

트랜잭션 또한 DBMS의 커넥션과 동일하게 꼭 필요한 최소의 코드에만 적용하는 것이 좋다. 이는 프로그램 코드에서 트랜잭션의 범위를 최소화하라는 의미이다.

다음 게시판 게시물 작성 후 저장하는 예시의 절차 중에서, DBMS의 트랜잭션 처리에 좋지 않은 영향을 미치는 부분을 살펴보자.

1) 처리 시작
	=> DB 커넥션 생성
	=> 트랜잭션 시작
2) 사용자의 로그인 여부 확인
3) 사용자 글쓰기 내용 오류 여부 확인
4) 첨부로 업로드된 파일 확인 및 저장
5) 사용자의 입력 내용을 DBMS에 저장
6) 첨부 파일 정보를 DBMS에 저장
7) 저장된 내용 또는 기타 정보를 DBMS에서 조회
8) 게시물 등록에 대한 알림 메일 발송
9) 알림 메일 발송 이력을 DBMS에 저장
	<= 트랜잭션 종료(commit)
	<= DB 커넥션 반납
10) 처리 완료

나쁜 영향을 주는 부분

• 많은 개발자가 DB 커넥션 생성(또는 풀에서 가져오는)하는 코드를 1번과 2번 사이에 구현하고 동시에 START TRANSACTION 명령으로 트랜잭션을 시작한다. 그리고 9번과 10번 사이에서 트랜잭션을 commit하고 종료(풀로 반납)한다. 실제로 DBMS에 데이터를 저장하는 작업(트랜잭션)은 5번부터 시작된다는 것을 알 수 있다. 그래서 2, 3, 4번의 절차가 빨리 처리된다고 하더라도 DBMS의 트랜잭션에 포함시킬 필요는 없다. 일반적으로 DB 커넥션의 개수가 제한적이어서 각 단위 프로그램이 커넥션을 소유하는 시간이 길어지면 여유 커녁센의 개수가 줄어든다. 어느 순간에는 각 단위 프로그램에서 커넥션을 기다려야 하는 상황이 발생할 수 있다.

• 더 큰 위험은 8번 작업으로 볼 수 있다. 메일 전송, FTP 파일 전송, 네트워크를 통해 원격 서버와 통신하는 작업들은 어떻게 해서든 DBMS의 트랜잭션 내에서 제외시키는 것이 좋다. 프로그램이 실행되는 동안 메일 서버와 통신할 수 없는 상황이 발생한다면 웹 서버뿐 아니라 DBMS 서버까지 위험해진다.

• 정보를 저장하는 5, 6번 작업은 반드시 하나의 트랜잭션으로 묶어야 하며, 7번 작업은 저장된 데이터를 확인하는 작업이므로 트랜잭션에 포함할 필요는 없다. 9번 작업은 성격이 다르기 때문에 이전 트랜잭션(5, 6번)에 함께 묶지 않아도 무방할 수 있다.

문제가 될 만한 부분을 보완해서 다시 설계해보자.

1) 처리 시작
2) 사용자의 로그인 여부 확인
3) 사용자 글쓰기 내용 오류 여부 확인
4) 첨부로 업로드된 파일 확인 및 저장
	=> DB 커넥션 생성
	=> 트랜잭션 시작
5) 사용자의 입력 내용을 DBMS에 저장
6) 첨부 파일 정보를 DBMS에 저장
	<= 트랜잭션 종료(commit)
7) 저장된 내용 또는 기타 정보를 DBMS에서 조회
8) 게시물 등록에 대한 알림 메일 발송
	=> 트랜잭션 시작
9) 알림 메일 발송 이력을 DBMS에 저장
	<= 트랜잭션 종료(commit)
	<= DB 커넥션 반납
10) 처리 완료

여기서 설명하는 바는 프로그램의 코드가 DB 커넥션을 가지는 범위와 트랜잭션이 활성화돼 있는 프로그램의 범위를 최소화해야 한다는 것이다. 프로그램 코드에서 적은 라인이라 하더라도 네트워크 작업이 있는 경우 반드시 트랜잭션에서 배제해야 한다.