728x90
Spring Batch에서 chunk 크기는 성능에 직접적인 영향을 줍니다.
이번 포스트에서는 100,005건의 데이터를 읽고 이름을 대문자로 변환한 뒤 DB에 저장하는 작업을 수행하면서,
chunk 크기에 따른 전체 처리 시간 차이를 측정했습니다.
💡 실험 조건
- 대상 데이터 수: 100,005건
- 작업 내용: 이름(firstName, lastName) → 대문자로 변환 후 DB insert
- 방식:
- 일반 insert (insert 반복 호출)
- bulk insert (<foreach> 사용한 List<Person> 단위 삽입)
- 환경: Spring Batch + MyBatis + H2 in-memory DB
📊 일반 Insert 성능 (단건씩 처리)
1차 | 2차 | 3차 | |
10 | 29.88초 | 30.13초 | - |
50 | 15.87초 | - | - |
60 | 15.66초 | - | - |
70 | 15.03초 | - | - |
80 | 19.99초 | 14.11초 | - |
90 | 18.55초 | 14.03초 | - |
100 | 13.60초 | 17.07초 | 14.52초 |
1000 | 12.44초 | - | - |
10000 | 11.57초 | - | - |
📌 해석
- chunk 50~100까지는 시간이 급격히 감소
- 하지만 일정 chunk 크기 이상(1000 이상)에서는 감소 폭이 줄어들고, 오히려 편차가 커지기도 함
- 단건 insert 방식의 경우 DB 커넥션 및 트랜잭션 처리 부하가 큰 편
⚡ Bulk Insert 성능 (MyBatis foreach 사용)
chunk | 1차 |
10 | 19.74초 |
50 | 6.95초 |
60 | 6.23초 |
70 | 5.89초 |
80 | 5.59초 |
90 | 5.34초 |
100 | 5.20초 |
1000 | 3.51초 |
10000 | 3.41초 |
📌 해석
- chunk가 커질수록 선형적으로 성능 향상
- 1000 이상에서는 거의 최적치 (3.4~3.5초) 도달
- insert가 1회에 몰려서 실행되므로 JDBC round-trip이 크게 줄어들고 CPU 부하도 작음
🧩 실험 요약 및 결론
- 단건 insert는 chunk 10에서 30초 가까이 소요되는 반면,
- bulk insert는 chunk 10000에서도 3.4초 수준으로 8~9배 성능 차이 발생
- chunk 크기와 bulk insert의 결합이 핵심 성능 향상 포인트
- 단, 너무 큰 chunk는 메모리 사용량 증가 및 rollback 범위가 커지므로 환경에 따라 조절 필요
🔧 추천 전략
데이터 건수추천 chunk 크기insert 방식
소규모 (< 10,000) | 100~500 | 일반 insert도 가능 |
중대형 (10,000~100,000) | 1000~5000 | bulk insert 강력 추천 |
대용량 (100,000 이상) | 1000~10000 | 필수로 bulk insert + 적절한 chunk 조절 필요 |
728x90
'BackEnd > Spring Batch' 카테고리의 다른 글
Spring Batch 실행 이력 테이블 분석 가이드 (0) | 2025.06.02 |
---|---|
Spring Batch + MyBatis 예제 정리 (CSV → DB 처리) (0) | 2025.06.02 |