7회차는 Spring Batch의 MyBatisItemReaderWriter/Writer에 대해 공부했습니다.
스터디 진행 전 교안을 공부하며 정리한 내용은 이곳에서 볼 수 있습니다.
스터디를 진행하면서 중요했던 내용들 몇 가지를 정리해보았습니다.
1. 마이바티스의 XML 방식과 인터페이스 방식 비교
- XML 방식
- 장점: 대규모 쿼리나 복잡한 SQL 작성 시 유리
- 단점: XML 파일과 코드 간의 연계 작업이 필요
- XML 파일에 쿼리를 직접 작성하여 사용하며, 복잡하거나 길이가 긴 쿼리를 작성하고 관리하기 용이합니다.
- 인터페이스 방식
- 장점: 간단한 쿼리를 빠르게 작성하고 관리하기 좋음
- 단점: 길고 복잡한 쿼리를 작성하기 어려움
- 애너테이션을 활용하여 인터페이스에 직접 쿼리를 작성할 수 있습니다.
인터페이스 방식으로 만든다면 아래와 같이 사용할 수 있습니다.
인터페이스 방식으로 작성하신 스터디원 분께서 공유해주신 코드입니다.
@Mapper
public interface CustomerMapper {
@Select("""
SELECT id, name, age, gender
FROM customer
LIMIT #{_skiprows}, #{_pagesize}
""")
List<Customer> selectCustomers();
}
긴 쿼리를 인터페이스 방식으로 작성하는 것은 비효율적이며, 이 경우 XML 방식을 사용하는 것이 더 적합하다고 하셨습니다.
2. 스프링 데이터(Spring Data)와 마이바티스 통합
- 스프링 데이터는 다양한 데이터베이스 기술(JPA, 마이바티스, MongoDB 등)을 통일된 방식으로 관리할 수 있도록 인터페이스로 처리할 수 있도록 도와주는 프레임워크입니다.
- 예: save, saveAll, findById 등의 메서드 지원
- 마이바티스와 스프링 데이터 통합
- 장점: JPA와 유사한 방식으로 CRUD 작업 수행 가능
- 활용 예시:
- findById: 특정 ID로 데이터 조회
- saveAll: 여러 데이터를 한 번에 저장
- 마이바티스와 통합하여 스프링 데이터처럼 사용할 수 있습니다.
3. 마이바티스의 배치 모드
- 배치 모드는 SQL 문을 메모리에 모아 두었다가, 설정된 청크 크기 단위로 DB에 한 번에 처리하는 방식입니다. 이를 통해 DB IO 횟수를 줄여 성능을 최적화할 수 있습니다.
- 배치 모드 작동 방식
- 데이터를 메모리에 모은다.
- 일정 크기(청크 크기)로 데이터를 한 번에 DB에 전달한다.
- 메모리를 비우고 새로운 데이터를 처리한다.
- 주의점
- 지나치게 큰 청크 크기를 설정하면 메모리 부족 문제가 발생할 수 있기 때문에 적절한 청크 크기를 설정하는 것이 중요합니다.
4. 페이징 처리 시 발생하는 문제와 해결 방법
- 문제
- 페이징 처리 시 쿼리에 ORDER BY를 생략하면 데이터 순서가 뒤죽박죽이 되어 중복 처리나 데이터 누락이 발생할 수 있습니다.
- 해결 방법
- 쿼리에 ORDER BY를 추가하여 데이터를 정렬
- 특정 컬럼(예: ID)을 기준으로 안정적인 정렬을 설정
예시:
페이징 처리 시 ORDER BY id를 추가하니 중복 및 누락 문제가 해결되었음
5. 마이바티스의 실무 활용과 특징
마이바티스는 여전히 많은 기업에서 사용되고 있습니다. SQL을 세밀하게 제어할 수 있기 때문에 복잡한 쿼리가 필요한 경우 유리하며, 다음과 같은 장점과 단점이 있습니다.
- 실무에서의 활용 사례
- 장점:
- SQL을 자유롭게 작성할 수 있어 복잡한 쿼리 작성이 가능
- 데이터베이스와 밀접하게 작업할 수 있어 세밀한 제어가 가능
- 단점:
- JPA에 비해 유지보수성이 떨어질 수 있음(쿼리 수정 시 연관된 코드를 모두 수정해야 함)
- 장점:
실무에서 마이바티스를 사용할 때는 JPA와의 조화를 고려하여 프로젝트의 규모와 요구 사항에 맞는 선택을 해야 합니다.(팀원이 마이바티스를 선호한다면 마이바티스를 채택하는 등 …)
6. 그 외 후기
마이바티스라는 이름은 자주 들어봤지만, 직접 사용하지 못해본 친구였습니다.
이번에 실무에서 사용 중인 SQL 쿼리를 보여주며 마이바티스를 이렇게 활용한다고 설명해주셔서 무척 신기했습니다.
특히 "SQL 쿼리를 하드하게 만든다"는 표현은 처음 들어봤는데요, 이는 데이터베이스를 활용해 비즈니스 로직을 단순화한다는 의미였습니다. 예를 들어 하드 쿼리에 대해 설명 드리겠습니다.
- 하드 쿼리: 데이터베이스에서 데이터를 가공해 원하는 결과를 바로 가져오는 방식
SELECT product_id, SUM(quantity) AS total_sales
FROM sales
WHERE sale_date BETWEEN '2024-01-01' AND '2024-12-31'
GROUP BY product_id;
- 데이터베이스가 모든 집계와 필터링을 처리하고, 최종 결과만 반환합니다.
2. 소프트 쿼리: 데이터베이스에서 원시 데이터를 가져와 애플리케이션에서 처리하는 방식
SELECT * FROM sales WHERE sale_date BETWEEN '2024-01-01' AND '2024-12-31';
- 애플리케이션에서 데이터를 그룹화하거나 합계를 계산해야 합니다.
데이터베이스에서 최적화된 연산을 활용하면 성능을 높일 수 있지만, SQL 쿼리가 복잡해지고 가독성이 떨어질 위험도 있습니다.
예시로 보여주신 하드 쿼리의 양도 상당했는데, 복잡하게 작성된 쿼리 하나를 이해하는 데만도 많은 시간이 걸린다고 하더라구요. 그만큼 ‘적절한 중간 지점’을 찾는 것이 어려울 것 같다는 생각이 들었습니다.
이번 경험 덕분에 raw SQL의 중요성을 다시 한번 느낄 수 있었고,
빠른 취업으로 실무에서 SQL 분석 작업을 직접 경험해보고 싶다는 생각이 들었습니다. 기대됩니다!! 😊😊
'알아두면 좋은 개발 지식 > Spring Batch 스터디' 카테고리의 다른 글
[9회차] 입맛에 맞는 배치 처리를 위한 Custom ItemReader/ItemWriter 구현방법 알아보기 (9) | 2024.12.14 |
---|---|
[8회차] CompositeItemProcessor 으로 여러단계에 걸쳐 데이터 Transform하기 (1) | 2024.11.28 |
[7회차] MyBatisPagingItemReader로 DB내용을 읽고, MyBatisItemWriter로 DB에 쓰기 (3) | 2024.11.16 |
[6회차] Spring Batch 스터디: 후기 및 추가 학습 내용 (2) | 2024.11.16 |
[6회차] JpaPagingItemReader로 DB내용을 읽고, JpaItemWriter로 DB에 쓰기 (2) | 2024.11.08 |