만약, 우리가 웹 페이지를 로드할 때, 동시에 모든 데이터를 다 불러와서 처리한다면 가장 먼저 걱정되는 건 무엇일까?
그건 당연히성능이다. 그렇기에 페이지네이션은 거의 필연적으로 구현해야 하는 기능이다.
즉, 페이지네이션이란? `특정한 정렬 기준 + 필요한 개수`의 조건에 맞춰 데이터를 가져올 수 있게 해주는 기능을 말한다.
보통 필요한 개수를 지정한 뒤 상황에 맞춰 정렬기준이 조건에 추가되는데,
이러한 조건을 맞춰 데이터를 가져오는 것을페이지네이션, 줄여서페이징이라고 한다.
위와 같은 페이지네이션을 처리하는 방법으로는 크게
오프셋 기반 페이지네이션(offset-based pagination)
커서 기반 페이지네이션(cursor-based pagination)
이 두 가지가 존재한다.
Offset-Paging(offset-based pagination)
`MySQL` 기준 `LIMIT` 쿼리를 사용하면 간단하게 구현이 가능하다.
N개의 데이터를 page - 1 만큼 Skip하고 그 다음부터 n개의 데이터를 요청하는 식이다.
SELECT * FROM users ORDER BY id DESC LIMIT 5,10; // 5개 skip후 10개 요청
SELECT * FROM users ORDER BY id DESC LIMIT 15 OFFSET 10;
SELECT * FROM users ORDER BY id DESC LIMIT 25 OFFSET 10; .....
위 처럼 비교적 구현하고 사용하기에 간단한 것이 `Offset-Paging` 방식이다.
하지만, `Offset-Paging` 방식에는 몇 가지 문제점이 존재한다.
1. CREATE 시 데이터 중복 출력의 문제
유저 1이 1페이지에 접속해서 5개의 데이터(`ㄱ~ㅁ`)를 확인했다고 가정하자.
이후, 유저2가 새 데이터 `ㅂ`와 `ㅅ`를 새롭게 등록했다면?
`ㄹ, ㅁ`를 중복해서 보게 된다.
만약, 동시에 많은 유저 접속해 새로운 데이터를 초당 10개씩 생성하는 서비스라면?
1페이지에서 봤던 10개의 데이터를 고대로 다시 보게 된다.
즉, 각각의 페이지를 요청하는 사이에 데이터의 변화가 있다면 중복 데이터가 노출되는 문제가 발생한다.
2. DELETE 시 데이터 누락의 문제
비슷하게 유저가 1페이지에 접속해서 5개의 데이터(`ㄱ~ㅁ`)를 확인하고,
이후 관리자가 `ㄱ, ㄴ`의 데이터를 삭제했다면?
사용자는새로고침을 하지 않는 이상 2페이지에 있던 `a`, `b`의 데이터는 볼 수 없다.
3. row 개수에 따른 성능 문제
데이터는 정렬 기준(`ORDER BY`)에 따라 row의 순서가 바뀌게 된다.
DB는 모든 경우에 따른 rownum을 갖고 있지 않기 때문에, 해당 row가 몇 번째 순서를 갖는지 알지 못한다.
요청한 데이터를 바로 조회할 수 없다. => 즉, 이전의 데이터를 모두 조회 후 그 `ResultSet`에서 offset을 조건으로 잘라내는 방식이다.
이는 row의 수가 많아지고 offset 값이 올라갈수록 쿼리의 퍼포먼스가 떨어지는 문제를 발생시킨다.
@RequiredArgsConstructor
public class CustomStudyRoomRepositoryImpl implements CustomStudyRoomRepository {
private final JPAQueryFactory jpaQueryFactory;
@Override
public List<StudyRoom> findAllWithPaginationAndCondition(int pageSize, GetStudyRoomCondition condition) {
return jpaQueryFactory.selectFrom(studyRoom)
.where(
studyRoomTitleContains(condition.getTitle()),
studyRoomHeadcountGoe(condition.getHeadCount()),
studyRoomPriceBetween(condition.getMinPricePerHour(), condition.getMaxPricePerHour()),
studyRoomOptionsContains(condition.getOptions()),
createSortPredicate(condition)
)
.orderBy(createOrderSpecifier(condition.getSortCriteria()))
.limit(pageSize)
.fetch();
}
private BooleanBuilder studyRoomTitleContains(String title) {
return this.nullSafeBuilder(() -> studyRoom.title.contains(title));
}
private BooleanBuilder studyRoomHeadcountGoe(int headCount) {
return this.nullSafeBuilder(() -> studyRoom.entireMaxHeadcount.goe(headCount));
}
private BooleanBuilder studyRoomPriceBetween(int minPricePerHour, int maxPricePerHour) {
return this.nullSafeBuilder(() -> studyRoom.entireMinPricePerHour.between(minPricePerHour, maxPricePerHour));
}
private BooleanBuilder studyRoomOptionsContains(List<StudyRoomOption> options) {
return options == null || options.isEmpty()
? null
: this.nullSafeBuilder(() -> studyRoom.optionInfos.any().option.in(options));
}
private BooleanBuilder createSortPredicate(GetStudyRoomCondition condition) {
Integer lastSortValue = condition.getLastSortValue();
Long lastStudyRoomId = condition.getLastStudyRoomId();
SortCriteria sortCriteria = condition.getSortCriteria();
Double lastAverageRating = condition.getLastAverageRatingValue();
return switch (sortCriteria) {
case STARS -> this.nullSafeBuilder(() -> studyRoom.averageRating.lt(lastAverageRating)
.or(studyRoom.averageRating.eq(lastAverageRating).and(studyRoom.id.lt(lastStudyRoomId))));
case LIKE -> this.nullSafeBuilder(() -> studyRoom.likeCount.lt(lastSortValue)
.or(studyRoom.likeCount.eq(lastSortValue).and(studyRoom.id.lt(lastStudyRoomId))));
case REVIEW -> this.nullSafeBuilder(() -> studyRoom.reviewCount.lt(lastSortValue)
.or(studyRoom.reviewCount.eq(lastSortValue).and(studyRoom.id.lt(lastStudyRoomId))));
case PRICE -> this.nullSafeBuilder(() -> studyRoom.entireMinPricePerHour.gt(lastSortValue)
.or(studyRoom.entireMinPricePerHour.eq(lastSortValue).and(studyRoom.id.lt(lastStudyRoomId))));
default -> this.nullSafeBuilder(() -> studyRoom.id.lt(lastStudyRoomId));
};
}
private OrderSpecifier<?>[] createOrderSpecifier(SortCriteria sortCriteria) {
return switch (sortCriteria) {
case STARS -> new OrderSpecifier<?>[]{
new OrderSpecifier<>(Order.DESC, studyRoom.averageRating),
new OrderSpecifier<>(Order.DESC, studyRoom.id),
};
case LIKE -> new OrderSpecifier<?>[]{
new OrderSpecifier<>(Order.DESC, studyRoom.likeCount),
new OrderSpecifier<>(Order.DESC, studyRoom.id),
};
case REVIEW -> new OrderSpecifier<?>[]{
new OrderSpecifier<>(Order.DESC, studyRoom.reviewCount),
new OrderSpecifier<>(Order.DESC, studyRoom.id),
};
case PRICE -> new OrderSpecifier<?>[]{
new OrderSpecifier<>(Order.ASC, studyRoom.entireMinPricePerHour),
new OrderSpecifier<>(Order.DESC, studyRoom.id),
};
};
}
private BooleanBuilder nullSafeBuilder(Supplier<BooleanExpression> f) {
try {
return new BooleanBuilder(f.get());
} catch (IllegalArgumentException | NullPointerException e) {
return null;
}
}
}
관련 K6 Script(studyroom-rps-test-cursor.js)
import http from 'k6/http';
import { check, sleep } from 'k6';
export const options = {
stages: [
{ duration: '10s', target: 300 }, // 300 VUs로 증가
{ duration: '10s', target: 200 }, // 200 VUs로 감소
{ duration: '10s', target: 200 }, // 유지
],
thresholds: {
http_req_duration: ['p(95)<500'], // 95% 요청이 500ms 이내에 응답
http_req_failed: ['rate<0.01'], // 에러율 1% 미만
},
};
const baseUrl = 'http://localhost:8080/api/v1/studyroom';
function getRandomSortCriteria() {
const criteria = ['STARS', 'LIKE', 'REVIEW', 'PRICE'];
return criteria[Math.floor(Math.random() * criteria.length)];
}
// 전역 변수로 Cursor 값을 유지
let sortCriteria = getRandomSortCriteria();
let lastSortValue = undefined;
let lastAverageRatingValue = undefined;
let lastStudyRoomId = undefined;
export default function () {
// Cursor 값을 기반으로 쿼리 파라미터 생성
const params = {
headCount: Math.floor(Math.random() * 10) + 1, // 1 to 10
minPricePerHour: Math.random() > 0.5 ? Math.floor(Math.random() * 10000) + 1000 : undefined, // Optional
maxPricePerHour: Math.random() > 0.5 ? Math.floor(Math.random() * 10000) + 2000 : undefined, // Optional
sortCriteria,
lastStudyRoomId,
};
// SortCriteria에 따라 Cursor 값 추가
if (sortCriteria === 'STARS') {
params.lastAverageRatingValue = lastAverageRatingValue;
} else {
params.lastSortValue = lastSortValue;
}
// QueryString 생성
const queryString = Object.entries(params)
.filter(([_, value]) => value !== undefined) // 필터링하여 정의되지 않은 값 제거
.map(([key, value]) => `${key}=${encodeURIComponent(value)}`)
.join('&');
const url = `${baseUrl}?${queryString}`;
// 요청 전송
const response = http.get(url);
// 응답 검사 및 Cursor 값 업데이트
check(response, {
'status is 200': (r) => r.status === 200,
'response contains valid data': (r) => r.json() && r.json().length >= 0,
});
const responseData = response.json();
if (responseData && responseData.length > 0) {
// 마지막 데이터의 Cursor 값 갱신
const lastItem = responseData[responseData.length - 1];
lastStudyRoomId = lastItem.id;
if (sortCriteria === 'STARS') {
lastAverageRatingValue = lastItem.averageRating;
} else {
lastSortValue = lastItem.sortValue;
}
} else {
// 응답이 비어있거나 Cursor 값이 0이면 정렬 기준 변경
if (sortCriteria === 'STARS' && (!lastAverageRatingValue || lastAverageRatingValue === 0)) {
sortCriteria = getRandomSortCriteria();
lastAverageRatingValue = undefined;
lastSortValue = undefined;
lastStudyRoomId = undefined;
} else if (sortCriteria !== 'STARS' && (!lastSortValue || lastSortValue === 0)) {
sortCriteria = getRandomSortCriteria();
lastAverageRatingValue = undefined;
lastSortValue = undefined;
lastStudyRoomId = undefined;
}
}
sleep(1);
}
Cursor K6 테스트에서는마지막 정렬 값이 0인 경우나 NULL인 경우새롭게 정렬 조건을 뽑아서 다시 요청하도록 코드를 작성했다.
결과
엥? `44.71ms`..? 이렇게 차이가 난다고..?(내가 잘못 테스트 한건가..)
(`1s -> 44.71ms..?`)
그러면.. 위 상태에서 인덱스까지 적용하면 어떻게 되는거지..?
인덱스 추가
CREATE INDEX idx_like_count_id ON study_room (like_count DESC, id DESC);
CREATE INDEX idx_review_count_id ON study_room (review_count DESC, id DESC);
CREATE INDEX idx_average_rating_id ON study_room (average_rating DESC, id DESC);
CREATE INDEX idx_entire_min_price_per_hour_id ON study_room (entire_min_price_per_hour ASC, id DESC);
다시 테스트...
결과
`44.71ms -> 9.27ms`로 또 한층 더 속도가 빨라졌다..
너무나도 `offset-based pagination`과 `cursor-based pagination`의 차이가 많이 나 이것저것 알아보았다.
조사해본 내용
`Offset`이 클 경우(예: 10,000개 이상), 데이터를 건너뛰는 비용이 증가하면서
1초 이상의 평균 응답 시간이 발생하는 것은 흔한 현상이라고 한다.
반면 `Cursor` 방식은 인덱스를 잘 활용하면 `44ms`처럼 대폭 단축되는 것이 가능하다고 한다.
오.. 충분히 흔한 결과구나..!!
하지만! 무조건 Cursor가 해답은 아니라는 사실을 명심해야 한다.
차이점을 바로 알고 넘어가자
1. Offset-based pagination으로도 성능 향상이 가능하다.
offset 기반에서도 `deferred join`, `covering index`, `complex index`를 사용하면 충분히 성능 향상이 가능하다.
