페이징의 종류와 각각의 장단점 (파이썬+장고)

 

 

장고에서 페이징은 크게 세 종류가 있다

 

1. Page Number Pagination

Front에서 요청을 날릴 때 특정 페이지 번호를 구분자(URI)에 붙여서
Back에서 받고 그 페이지에 맞는 데이터를 필터링해서 응답해주는 방식

 

 

예시)

/api/items/?page=3

 

장점)

직관적이고 간단해서 적용하기 쉽다

 

단점)

대용량 조회에 적합하지 않다. 적합하지 않은 이유는 Limit Offset Pagination과 마찬가지로 동작원리에 있다.

특정 페이지, 예를 들어, 999페이지를 요청했다고 가정하면 서버는 999페이지에 도달하기 위해 처음부터 989 페이지까지 쭉 확인하면서 스킵해야 하는데 확인하고 스킵하는 것도 시간이 걸리는 법이다.   

 

2. Limit Offset Pagination

Front에서 요청을 날릴 때 시작점(offset)과 끝점(limit)을 Back에 전달하고
Back 이 그 범위에 해당하는 데이터만 잘라서 응답하는 방식

 

장점)

마찬가지로 직관적이고 간단한데

페이지 사이즈의 미세 조정이 쉬워서 유연하고 이어붙이는 무한 스크롤을 구현하기 쉽다.

 

단점)

대용량 조회에 적합하지 않다.

적합하지 않은 이유는 Page Number Pagination과 마찬가지로 동작원리에 있다.

offset을 계산하기 위해 많은 비용이 들어가기 때문이다. 비용이 들어가기 때문에 뒤로갈수록 느려지게 된다.

 

이게 무슨말이냐하면..

한 페이지에 10개의 행을 보여주는 페이징을 도입한뒤 특정 조건을 걸어서 조회를 했더니

2000개의 행이 조회되었다고 가정해보자. 약 200 페이지가 생길 것이고 

중간쯤 가서 99페이지를 눌러서 991 ~ 1000 사이의 행을 잘라서 응답받길 원한다면

서버는 991번의 인덱스를 도달하기 위해 전체 데이터인 1부터 2000번까지를 일단 스캔하고 가져온 뒤

0부터 990번까지의 인덱스를 모두 스캔하고 스킵해야 하기 때문이다. 

 

 

3. Cursor Pagination

Front에서 요청을 날릴 때  커서(cursor)라는 고유한 구분자를 Back에 전달하고
Back은 이 커서를 기준으로 바로 앞, 혹은 바로 다음에 해당하는 것만 응답하는 방식

 

장점)

뒤로갈 수록 느려지지 않고 일정한 조회시간을 갖는다.

고로, 대용량 조회에 최적화 되어있다.

 

이러한 특징 및 장단점 때문에 뒤로 갈수록 유리해지는 커서 페이징은 그 효율이 그래프로 보면 바로 눈에 들어온다.

 

단점) 

다른 페이징 보다 구현 난이도가 높다.

원하는 페이지로 직접 갈 수 있는 방식을 제공하지 않는다.

그야말로 내가 지금 보고 있는 페이지 기준으로 앞과 뒤밖에 갈 수 없다.

 

*번외)

그렇다면 만약 대용량 조회가 요구되면서

단순히 앞 뒤가 아니라 특정 페이지로 바로 접근하고도 싶다면 어떻게 해야할까?

바로 Cursor Pagination 의 장점은 그대로 살리면서  Page Number Pagination 혹은 Limit Offset Pagination의 특징 중 하나인 특정 구간 scan을 재현하면 된다. 이 방법에 대해서는 다음 포스트에 설명하도록 하겠다.