페이지네이션 방법론 비교(Offset vs Cursor)

페이지네이션이란?

OLTP 환경에서 사용자에게 반환되는 데이터들은 대부분 특정 기준으로 정렬된 일부 데이터이다. 

예를 들면 웹개발의 가장 흔한 예시인 게시판이 그렇다. 게시판은 일반적으로 한 페이지에 약 20개의 게시글들을 최신순으로 노출시키고, 사용자가 다음 페이지로 넘어가게 되면 21 ~ 40번째 데이터가 그제서야 조회되는 방식으로 구현된다.

이 상황에서 서버는 사용자에게 전체 게시글 데이터를 전달하는 것이 아닌, 사용자가 위치한 페이지에 해당하는 데이터만을 반환하도록 API 설계가 이루어지는데 이를 페이지네이션 방법론이라고 부른다.

 

 

페이지네이션 종류

일반적으로 많이 사용되는 페이지네이션 기법에는 Offset 기반 페이지네이션과 Cursor(Keyset) 기반 페이지네이션이 존재한다.

Offset 기반

Offset 기반 페이지네이션 기법은 페이지네이션을 다룰 때 가장 많이 등장하는 방식이다.

바로 위에서 예시로 든 게시판 구현에도 주로 이 방식이 사용된다.

예시를 위해 post 테이블이 아래와 같이 작성되어 있다고 가정하자. 이 때 전체 row 수는 50,000이고, 기준 DB는 Mysql이다.

CREATE TABLE post (
    id INT AUTO_INCREMENT PRIMARY KEY,
    user_id INT,
    name VARCHAR(30),
    content TEXT,
    created_at TIMESTAMP
);

CREATE INDEX idx_post_created_at ON post(created_at);

이 때 Offset 기반 페이지네이션 쿼리는 아래와 같이 작성된다.

SELECT * 
FROM post
ORDER BY created_at DESC
LIMIT 20 OFFSET 20 * {page - 1};

쿼리가 상당히 간단하게 구성되는데, 이는 Offset 기반 페이지네이션의 장점 중 하나이다. 클라이언트 측에서는 페이지네이션을 구현하기 위해 서버 측에 단순히 페이지 정보와 페이지 당 데이터 수, 마지막으로 정렬 기준 만을 전달하면 된다.

위 쿼리로 첫번째 페이지를 조회하는 상황의 실행 계획은 아래와 같다.

1 페이지 조회 실행 계획

실행 계획을 잘보면 쿼리가 DB에서 접근한 rows 수가 단 20에 그치는 것을 알 수 있다. 이는 전체 50,000개의 row를 전부 확인하지 않고 필요한 부분만을 읽어내고 있다고 볼 수 있다. 이는 인덱스를 통해 이미 정렬이 되어 있는 상황에서 딱 필요한 데이터 만큼을 읽을 수 있었기 때문이다.

이러한 패턴 때문에 최적화된 Offset 기반 페이지네이션 환경에서는 테이블의 데이터가 아무리 많아도 첫번째 페이지를 읽어오는데 오래걸리지 않는다.

이제 두번째 페이지를 조회하는 실행 계획을 확인해보자.

2 페이지 조회 실행 계획

이번에도 20개의 데이터만을 읽을 것으로 생각할 수 있지만 LIMIT OFFSET 쿼리는 그렇게 동작하지 않는다.

만약 LIMIT A OFFSET B라고 한다면, DB 옵티마이저는 A+B만큼의 데이터를 테이블에서 읽어낸 뒤 불필요한 부분은 버리는 식으로 동작한다. DB가 인덱스 탐색을 수행할 때 오프셋 정보를 수직적 탐색에 이용할 수 없기 때문에 이와 같이 동작한다.

따라서 Offset 기반 페이지네이션은 페이지가 뒤로 갈수록 읽어야 할 데이터의 총량이 많아져 성능이 저하되는 특성을 갖는다.

요약

• 구현, 쿼리 구성이 상당히 간단하다.
• 최적화된 Offset 기반 페이지네이션 환경에서는 테이블 내 데이터가 아무리 많아도 첫 페이지 데이터를 가져오는데 오래걸리지 않는다.
• 확인해야 할 페이지가 뒤로 갈수록, 읽어야 하는 데이터의 총량이 선형적으로 증가하여 성능이 저하된다.

 

Cursor(Keyset) 기반

Cursor 기반 페이지네이션 기법은 무한 스크롤을 구현할 때 흔히 접할 수 있는 방식이다.

위에서 사용한 테이블을 그대로 사용하는 상황에서 Cursor 기반 페이지네이션 쿼리는 아래처럼 작성할 수 있다.

SELECT *
FROM post
WHERE created_at < {:cursor}
ORDER BY created_at DESC
LIMIT 20;

위 쿼리를 보면 알 수 있지만, Cursor 기반 페이지네이션을 구현하기 위해서는 클라이언트 측에서 커서 데이터를 따로 유지하다가 요청 시 포함해주어야 한다. 위 예시에서는 크게 어려워보이지 않지만, 정렬 기준이 많아지는 환경에서는 클라이언트 측이나 서버 측 모두 구현에 부담이 될 수 있다.

해당 방식을 활용할 때 가장 먼저 실행되는 쿼리의 실행 계획은 아래와 같다.

Cursor 페이지네이션 방식의 첫 쿼리

실행 계획을 보면 Offset 기반 페이지네이션 방식의 1페이지 요청 쿼리와 완전히 동일하다. 이를 통해 Cursor 기반 페이지네이션 방식 또한 테이블을 전부 확인하는 것이 아니라 필요한 부분의 데이터 만을 효율적으로 읽을 수 있음을 알 수 있다.

이제 스크롤을 조금 더 내려서 다음 20개의 데이터를 불러오는 상황의 쿼리를 작성해보자. 위 쿼리를 실행했을 때 마지막 데이터의 created_at 칼럼 값은 '2023-12-30 10:35:25' 이므로 이를 커서로 활용하자. 실행 계획은 아래와 같다.

Cursor 페이지네이션 방식의 두번째 쿼리

페이지의 값이 커짐에 따라 읽어야 하는 데이터의 양도 선형적으로 증가하는 Offset 기반 방식과는 달리, Cursor 기반 방식은 여전히 20개의 row만을 읽어낸다. 이는 DB가 커서 값을 통해 인덱스 탐색 시작 지점을 곧바로 찾을 수 있기 때문에 가능한 일이다.  따라서 해당 방식은 커서가 뒤로 많이 간 상황에서도 항상 일정한 성능을 보장하는 특성을 갖는다. 

그렇다면 구현 난이도적인 문제만 해결하면 항상 Cursor 기반 페이지네이션을 사용해야 하는 것이 아니냐고 이야기할 수 있다. 하지만 이에도 제약이 존재한다. 눈치가 빠른 사람들이라면 이미 알아챘겠지만, 위 예제 쿼리는 큰 문제를 안고 있다. 만약 완전히 같은 시점에 작성된 post가 존재하여 created_at 칼럼이 완전히 동일한 row가 존재할 수 있다면? 이 경우 Cursor 기반 방식은 출력 데이터에 일관성을 보장할 수 없다. cursor 값으로 사용되는 데이터 집합은 테이블 상에서 유일성이 보장되어야 한다는 것이다. 물론 cursor 셋에 칼럼을 추가하여 유일성을 보장할 수 있지만 이 경우 인덱스의 수정 및 크기 증가, 구현의 복잡성이 증가하는 문제 등이 발생한다. 

또한 Cursor 기반 방식은 한번에 여러 데이터를 건너 뛰어야 하는 요구사항(ex. 불연속적인 페이지 이동)에서는 좋은 방안이 아니다. 왜 그런건지는 여기까지 글을 읽었다면 곧바로 이해하리라 생각한다.

요약

• Cursor 기반 방식은 Offset 기반 방식에 비해 구현이 복잡하다.
• 최적화된 Cursor 기반 페이지네이션 환경에서는 테이블 내 데이터가 아무리 많아도 빠른 응답 속도를 보일 수 있다. 또한 커서가 점차 뒤로 가더라도 일정한 성능을 보장한다.
• Cursor 기반 방식에서 커서 값으로 활용되는 데이터 셋은 테이블 내에서 유일성이 보장되지 않을 경우 결과 집합의 일관성을 보장할 수 없다.
• 한번에 여러 데이터(페이지)를 건너 뛰어야 하는 요구사항이 존재한다면 좋은 선택지가 아니다.

 

 

여담

위에서 살펴본 페이지네이션 기법들은 언제까지나 테이블 인덱스가 적절하게 구성이 되어 있어야 성능 상 이점을 볼 수 있다.

인덱스가 없어도 쿼리의 결과집합이 달라지거나 하지는 않지만 결국 정렬된 데이터를 기반으로 부분 처리를 수행하는 방식이기 때문에 필요한 데이터 만을 DB에서 읽기 위해선 정렬 작업을 건너 뛸 수 있는 인덱스 설계가 필요하다.

만약 그렇지 않다면, 매번 테이블 전체를 확인한 뒤 목표 데이터를 따로 걸러주는 실행 계획이 도출되기 때문에 페이지네이션 도입을 통한 성능 개선의 이점은 바랄 수 없다.