대용량 조회
한 줄 정의
대용량 조회는 많은 데이터를 메모리, DB 부하, 정렬 안정성, 재시작 가능성을 고려해 나누어 읽는 방식이다.
실무에서 왜 문제 되는가
- 전체 데이터를 한 번에 로딩하면 OOM이나 긴 GC가 발생할 수 있다.
- 큰 offset은 뒤 페이지로 갈수록 scan 비용이 커진다.
- 처리 중 데이터가 변경되면 offset 기반 조회에서 누락과 중복이 생길 수 있다.
- 정렬 기준이 불안정하면 같은 데이터가 여러 번 읽히거나 빠질 수 있다.
실무 판단 기준
| 상황 | 선택 |
|---|---|
| 큰 목록 순차 처리 | keyset pagination |
| 정렬 기준 필요 | unique하고 증가하는 key |
| 읽기 전용 대량 처리 | stream/cursor 검토 |
| 재시작 필요 | 마지막 처리 key 저장 |
자주 나는 실수
select *로 필요한 것보다 많은 컬럼을 읽는다.- offset pagination으로 배치 전체를 처리한다.
- 정렬 조건 없이 limit만 사용한다.
- count query 비용을 무시한다.
확인 방법
- 실행 계획에서 scan row, index, filesort 여부를 확인한다.
- 처리 중 데이터 추가/수정이 있어도 누락이 없는지 테스트한다.
- 메모리 사용량과 fetch size를 확인한다.
핵심 요약
배치 대용량 조회는 빠른 조회보다 안정적인 순회가 중요하다.
offset은 데이터가 많아질수록 비용이 커지고 변경 중 데이터에 취약하다.
keyset 방식은 마지막 처리 key를 기준으로 다음 범위를 읽기 좋다.
정렬 기준은 안정적이고 가능하면 unique해야 한다.
필요한 컬럼만 읽고 실행 계획으로 비용을 확인해야 한다.
꼬리 질문
- Batch에서 offset pagination이 위험한 이유는 무엇인가?
- 마지막 처리 위치는 무엇으로 저장할 것인가?
- Stream 조회와 chunk 조회는 어떻게 선택할 것인가?