Index
데이터의 양이 증가하면서, 페이지네이션은 소프트웨어 개발의 필수적인 부분이 되었다.
Request 마다 큰 용량의 데이터를 내려주는것 대신에, 페이지네이션은 더 작은 용량으로 나누어 클라이언트에게 데이터를 전달 해 줄 수있다.
Cursor 페이지네이션과 Offset 페이지네이션은 각각의 장단점을 가지고 있는 일반적인 알고리즘이다.
Offset Pagination
우리가 알고 있는 일반적인 Pagination 이 Offset Pagination 이다.
Offset 페이지네이션은 offset과 limit을 SQL 명령어를 통해 데이터를 가져온다.
API: GET /api/user/list
request: {
page_size: 10,
page_number: 3
}각각의 request에 클라이언트는 page_size(offset)와 page_number(limit)를 payload에 실어서 전달한다.
- Page Size는 반환할 데이터의 개수를 나타낸다.
- Page Number는 현재 요청중인 페이지를 나타낸다.
만약 Page Number 가 2이고, Page Size 가 10이라면,
서버는 21(PageNumber PageSize + 1)번부터 30((PageNumber + 1) PageSize) 번까지의 데이터를 내려주게 될것이다.
response: {
"users": [...],
"paging": {
"total_record": 295,
"page": 3,
"total_pages": 30
}
}장점
- 총 recode개수와 Page크기를 알 수 있다.
이는 사용자가 원하는 페이지를 선택하고 바로 그 페이지의 데이터를 볼 수 있다는 것을 의미한다.
단점
- 데이터가 불일치 할 수 있다.
만약 사용자가 어떤 게시물의 1페이지부터 +1 씩 증가하면서 다음 페이지의 데이터를 보는 도중, 게시물이 삭제된다면 페이지의 데이터가 하나씩 앞으로 이동하며 사용자가 보지 못하고 넘어가는 게시물이 생길 수 있다.
반대로 게시물이 하나 추가된다면, 사용자는 이전 페이지에서 넘어온 게시물을 한번 더 보게 되는 케이스가 생길 수 있다.
- 데이터의 총 개수를 보기 위해 쿼리의 시간이 급격하게 늘어날 수 있다.
Cursor Pagination
Cursor 페이지네이션은 페이스북의 무한 스크롤 또는 더보기 버튼을 클릭해 다음 데이터를 불러오는 방식이다.
Cursor 페이지네이션은 현재 보고있는 데이터의 마지막 번호인 Cursor와 몇개의 데이터를 불러올 것인지에 대한 page_size 를 통해 서버이 데이터를 호출 할 수 있다.
API: GET /api/user/list
request: {
cursor: 12345,
page_size: 10
}만약 커서가 제공되지 않는다면 서버는 첫번째 데이터에서 page_size 만큼의 데이터를 가져오게 된다.
만약 server를 통해 받은 데이터의 개수가 page_size 보다 작다면, 데이터의 마지막을 의미한다.
response: {
"users": [...],
"next_cursor": "12335",
}client 는 next_cursor를 이용해 다음 데이터를 계속해서 호출 할 수 있다.
장점
- 데이터의 추가 삭제에 안정적이다.
이전 offset Pagination 에서와는 다르게 데이터의 추가, 삭제에도 중복된 데이터를 만들거나 데이터를 보지 못하는 케이스가 발생하지 않는다.
- 대규모 데이터에 적합한 확장성을 가지고 있다.
cursor의 데이터가 인덱싱 되어 있다는 전제하에, database는 cursor를 바로 찾을 수 있고, 원하는 갯수만큼의 데이터를 효율적으로 불러 올 수 있다.
데이터의 양이 많아질 수록 offset 페이지네이션에 비해 더 효율 적이다.
단점
- 사용자가 원하는 페이지로 바로 이동 할 수 없다.
cursor기반 페이지네이션은 총 데이터의 개수를 알 수 없어, 원하는 페이지로 바로 이동하는 것이 불가능합니다.
- 정렬 기능이 제한된다.
고유(unique)하지 않은 데이터 이름과 같이 중복이 많이 허용되는 데이터로 정렬해야하는 경우, 시간 복잡도가 증가하고 구현하기 어렵다.
결과
offset 기반 페이지네이션과 cursor 기반 페이지네이션에 대해 보고 기본적인 자료구조에서 배열과 링크드리스트의 형태와 많이 닮았다는 생각이 든다.
배열은
빠른 엑세스가 가능하지만, 추가 삭제에 영향을 크게 받는다는 것이 offset 기반 페이지네이션과 닮았고,
링크드 리스트는
원하는 페이지에 엑세스 하기 위해 앞의 데이터를 순차적으로 확인해봐야해서 오래 걸리지만, 추가 삭제에 적은 영향을 받는것이 많이 비슷하다 느꼇다.
위 두 페이지네이션도 어떤 알고리즘이 더 좋다고 말 할 수 없다.
장단점을 비교하고 어떤게 적절한 경우인지를 생각해서 도입하는 것이 좋다고 생각한다.
출처
