페이지네이션 Offset기반과 Cursor기반 Pagination 차이점

📌 페이지네이션

많은 양의 데이터가 있을 때 서버에서 모든 데이터를 한번에 가져오는 것은 서버입장에서도 클라이언트 입장에서도 좋은 방식이 아니다. 따라서 "특정한 정렬 기준"과 "지정된 갯수"의 데이터를 가져오는 것이 필요하다. 이를 페이지네이션(Pagination)이라고 하는데 찾아보니 페이지네이션 구현 방법은 크게 두가지 방식으로 처리 가능하다.

 

1. 오프셋 기반 페이지네이션 (Offset-based Pagination)

2. 커서 기반 페이지네이션 (Cursor-based Paginantion)

 

1번의 방법이 구현하는데 있어서 쉬운 방법이지만 여러가지 문제점이 존재한다. 그렇기 때문에 웬만해선 2번의 방법으로 페이지네이션을 구현하는게 좋다고 한다. 1번의 어떤 문제가 존재하는지 살펴보고 2번에 대해서 알아보고자 한다.

 

🔑  1. 오프셋 기반 페이지네이션 (Offset-Based Pagination)

가장 일반적인 방법으로 MySQL에서 간단히 LIMIT쿼리에 콤마를 사용해 건너 뛸 숫자를 지정하면 된다.

SELECT id FROM 'reservations' ORDER BY id DESC LIMIT 10, 20

LIMIT절에 붙는 숫자를 통해 건너 뛸 갯수(offset)을 지정해주면 된다.

오프셋 = (현재 페이지 번호 -1) * 페이지 당 요청하는 자료 갯수이다.

 

위 방식은 id를 기준으로 정렬된 값에서 지정된 갯수를 보여주기 때문에 "데이터 변화가 있을 경우"와 "쿼리의 퍼포먼스 이슈의 문제"가 존재한다. 조금 더 풀어서 설명하자면 SNS 서비스와 같이 데이터의 인아웃이 활발하게 존재하는 경우 1페이지에서 2페이지로 넘어갔을 때 1페이지에서 봤던 데이터가 새로운 데이터 유입으로 2페이지에서도 보여질 수 있다. RDBMS에서 모든 정렬 기준에 대해 row수가 아주 많은 경우 offset값이 올라갈수록 쿼리의 퍼포먼스는 이에 비례해서 떨어지게 되어 있다. 그렇기 때문에 offset 기반 페이지네이션은 아래와 같은 경우에 사용하기 적절하다.

 

1. 데이터의 변화량이 적어 중복 데이터가 노출될 확률이 적은 경우

2. 중복 데이터가 노출되어도 크게 문제가 없는 경우

3. 검색엔진이 인덱싱 할 이유도, 유저가 마지막 페이지를 갈 이유가 없는 경우

4. row수가 많지 않아 퍼포먼스 이슈를 걱정할 필요가 없는 경우

 

🔑  2. 커서 기반 페이지네이션 (Cursor-based Pagination)

커서 기반 페이지네이션은 우리가 책을 읽을 때에 '책갈피'라고 생각하면 이해가 쉽다. 오프셋 기반 페이지네이션은 데이터가 몇 번째에 있다는데에 집중하고 있다면 커서 기반 페이지네이션은 데이터가 어떤 데이터의 다음에 있는지에 집중한다. 

SELECT id FROM 'reservations' WHERE id > 10 ORDER BY id ASC LIMIT 5

위의 경우 Cursor가 reservations테이블의 id이고 값은 10이다. 10보다 큰 데이터들을 기준으로 다음 데이터를 요청한다.

id값의 경우에는 고유값이기 때문에 문제가 없지만 price와 같이 중복값이 되는 경우에는 데이터를 불러오는데 어려움이 있다. 때문에 id와 price 값을 이용하여 가져와야 한다.

SELECT id, price
FROM 'reservation'
WHERE (price > 10000 OR (price = 10000 AND id > 10))
OREDER BY price ASC, id ASC
LIMIT 5

 

이렇게 할 경우 책을 읽을때 사용하는 책갈피 처럼 기준점 다음이 되는 데이터를 불러올 수 있다.