Cursor Pagination으로 조회 API 성능 개선
Jul 24, 2024
1. 문제 상황
SOL- 개요 : 프로그램을 만드는 저작도구
- 사용자 : 프로그램을 만드는 사람
- 프로그램을 만들 때 사용할 이미지를 보여줄 때 모든 이미지를 한 번에 다 조회
화면 캡쳐 : 이미지를 조회하는 API
화면 캡쳐 : 이미지 조회 API의 응답 크기 : 6.9MB
2. 문제 원인
- 이미지를 가져오는 쿼리 : 한 번에 과목에 해당하는 이미지를 다 조회함
SELECT (imageId), (...), ...
FROM (image 테이블)
WHERE subjectCode = '{subjectCode}'3. 문제 해결 방안 : 페이지네이션
- 대량의 데이터를 한 번에 가져오는 것이 문제 → ∴ 페이지네이션을 적용하기로 함
- Offset-based Pagination
- Cursor-based pagination
ㅤ | Offset Pagination | Cursor Pagination |
구현 난이도 | 간단함 | 복잡함 |
ㅤ | ㅤ | ㅤ |
특정 페이지로 이동 | O | X (연속된 페이지로 이동) |
확장성 | 낮음
(데이터 ↑ → 성능 ↓) | 높음 |
성능 | 나쁨
(offset이 커질 수록 Full Scan) | 좋음 |
데이터 중복/누락 발생 | O | X |
코드 예시 | SELECT * FROM posts ORDER BY created_at DESC LIMIT 10 OFFSET 10; | SELECT * FROM posts WHERE created_at < 'last_created_at' ORDER BY created_at DESC LIMIT 10; |
4. 문제 해결 : Cursor Pagination 적용
- 실제 사용자 피드백 : 특정 페이지로 이동하는 기능이 필요함
- 비어있는 항목을 찾기 위함
- 따라서 Cursor 방식과 Offset 방식을 혼합하여 특정 페이지로 이동하는 기능 추가
- 추가로
비어있는 항목만 조회할 수 있는 기능추가
5. 결과
- 성능 비교
- 첫 페이지
- 다음 페이지
ㅤ | SOL | SOL2 |
Resource Size | 6.9MB | 2.8KB |
Response time | 654ms | 20ms |
ㅤ | SOL | SOL2 |
Resource Size | - | 3.1KB |
Response time | - | 114ms |
화면 캡쳐 : 첫 페이지 조회 API
화면 캡쳐 : 다음 페이지로 이동 API
Share article
