본문 바로가기
IT/Java

[iBATIS 2.x] 일괄처리, 트랜잭션 성능

by yjacket 2010. 11. 11.
iBATIS 2.x 는 대량의 insert, update, delete 작업을 효율적으로 처리 할 수 있는 방법으로 startBatch(), executeBatch() 메서드를 제공한다.

개발자 가이드에 의하면 네트워크 트래픽 최소화, JDBC 드라이버의 추가적인 최적화(압축같은) 같은 혜택을 통해 성능향상을 볼 수 있다고 한다.

startBatch(), executeBatch() 메서드는 문서상으로 명시적 transaction 과 함께 사용해야 한다고 나오지는 않았으나
테스트시에는 명시적 transaction 을 사용하지 않았을때는 일반작업과 동일하거나 나쁜 결과를 보였다.

1. 특징

UPDATE 문 1000번 반복 처리 속도 테스트 결과
1) 배치+트랜잭션 : 77ms
2) 트랜잭션 : 1104ms
3) 일반작업 : 4274ms
4) 배치 : 4604ms

다음은 "UPDATE Computers SET ..." 문을 배치로 10번 실행하는 부분의 디버그 로그다.



그리고 다음은 같은 UPDATE 문을 배치하지 않고 트랜잭션만 걸린 상태로 10번 실행한 부분의 디버그 로그다.



배치 적용 유무에 따른 속도 차이는 상황에 따라 많이 다르지만 위 테스트에선 대략 5~7배 정도 차이를 보였다.

위 테스트에서 트랜잭션까지 빼면 디버그 로그는 다음과 같이 나온다.



위 테스트는 트랜잭션만 건 테스트에 비해 3-5배정도 느리게 나왔다.
트랜잭션없이 배치만 걸면 위 테스트와 비슷하거나 더 느린 결과를 보였다.

2. 장점
동일유형의 작업을 빠르게 처리 한다. 테스트시 최대 50배이상 빠르게 실행되는 경우도 있었다.

3. 단점
작업실패시 모든 배치가 롤백된다.
- 롤백하지 않고 실패한건만 무시하고 계속 진행하고 싶은 경우엔 해결 방법이 없다.
문제가 발생했을때 어디서 발생했는지 알기 어렵다.
- executeBatch() 메서드는 성공한 업데이트 수를 반환한다. 단, insert, update, delete 에 한한다.queryForObject 의 수행결과는 알 수 없다
- executeBatchDetail() 메서드는 더욱 상세한 모든 배치작업결과를 반환한다. 하지만 역시 insert, update, delete 에 한한다.
- 또 작업중 예외가 발생하면 배치예외를 던지는데, 어떤 문장(statement)에서 예외가 발생했는지는 보이지만 동일한 문장을 배치작업으로 여러개 수행하는 경우라면 어느 부분에 문제가 발생했는지 알 수 없다.

위와같은 한계로 배치 중 오류발생시 무시하고 다음으로 진행하고 싶을땐 배치할 작업을 저장해두고 있다가 예외를 잡아 일반작업으로 넘겨 처리해줘야 하는 불편이 있다.
※ 배치예외, 배치결과객체 분석이 충분하지 않아 단점으로 지적한 부분에 문제가 있을수도 있다.

*4. 결론*
동일작업을 대량 반복할때 배치, 트랜잭션은 성능을 대폭 향상시킨다.
배치예외가 빈번히 발생하는게 아니라면, 예외시 일반작업 처리를 위한 대비 코드를 사용하는 비용을 치르더라도 배치를 쓰는게 좋다.


'IT > Java' 카테고리의 다른 글

[iBATIS 2.x] insert 성공 여부 판단  (0) 2010.11.18
[iBATIS 2.x] 트랜잭션 동시성 문제 있을까?  (0) 2010.11.16
Java Tip #2 : 큐(Queue) 성능 테스트  (1) 2010.11.09
Spring - iBATIS : 웹서버 시작시 jdbc.properties 를 읽지 못해도 무시하게 하자  (0) 2010.07.14
Spring - iBATIS : dataSource 의 동적 로딩  (2) 2010.07.14

관련글

티스토리툴바