페이징 처리를 왜하는걸까?
애플리케이션에 저장된 모든 데이터를 한 번에 가져와 보여주는 것은 메모리 사용량 증가 및 응답 시간 지연을 발생시키며, 그로 인해 서버, DB, 클라이언트 모두에 부하가 생기게 된다.
또한, 한 번에 너무 많은 데이터를 보여주면 사용자 입장에서 가독성이 떨어지고 탐색이 불편해진다.
따라서 페이징 처리를 통해 데이터를 적절히 나누어 제공함으로써 성능과 사용자 경험을 동시에 향상시킬 수 있다.
페이징 처리에는 다음과같이 2가지 방식이 존제하는데
1. 번호 기반 페이지(Pagination)
페이지 번호를 기반으로 데이터를 나누어 요청하는 방법으로, 구현이 간단하고 이전/다음 페이지에 대한 탐색이 명확하지만 데이터가 자주 변경된다면 페이지의 내용이 달라질 수 있다.
2. 무한 스크롤(Infinite Scroll)
사용자가 화면을 아래로 스크롤 할 때마다 자동으로 데이터를 불러오는 방법으로, 사용자의 몰입감이 좋지만 페이지 구분이 없어 위치에 대한 파악이 어렵다.
번호 기반 페이지(Pagination)
번호 기반 페이지(Pagination)는 일반적으로 OFFSET과 LIMIT 또는 페이지 번호 기반으로 데이터를 잘라 가져오게 된다.
SELECT * FROM article ORDER BY created_at DESC LIMIT 10 OFFSET 20
이 때, 인덱스의 설계와 활용 여부에 따라 페이징 성능이 크게 달라질 수 있다.
Clustered Index (클러스터형 인덱스)
클러스터형 인덱스는 데이터 자체가 정렬된 상태로 저장되는 인덱스 구조이다.
MySQL InnoDB 기준으로는 기본 키(Primary Key)가 자동으로 클러스터형 인덱스가 된다.
페이지 번호 기반의 페이징에서 order by id 또는 order by created_at과 같은 정렬 기준이 클러스터형 인덱스를 기반으로 할 경우,
빠르게 정렬된 데이터를 탐색할 수 있기 때문에 페이징 성능이 향상된다.
SELECT * FROM article ORDER BY id LIMIT 10 OFFSET 1000
→ id가 클러스터형 인덱스일 경우 빠르게 처리됨.
Secondary Index (보조 인덱스)
보조 인덱스는 클러스터형 인덱스가 아닌 컬럼에 생성되는 인덱스이다.
보조 인덱스를 사용한 페이징은 인덱스 → PK → 데이터 순서로 접근하게 되어 추가적인 I/O 비용이 발생할 수 있다.
특히 보조 인덱스를 기준으로 order by 또는 where 조건이 걸리면 페이징 시 성능 저하가 발생할 수 있다.
SELECT * FROM article ORDER BY title LIMIT 10 OFFSET 1000
→ title이 Secondary Index일 경우, 랜덤 접근으로 인해 느려질 수 있음.
