← 목록으로
DEVLOG · education
2026-06-15

페이지네이션(limit, offset)과 파티션닝

pagination

1. RDBMS에서 파티션 vs 페이지네이션

1) 파티션(Partition)이란?

단일 데이터베이스 테이블을 거대한 하나의 파일로 저장하지 않고, 특정 기준(날짜, ID 범위 등)에 따라 물리적으로 여러 개의 저장 공간(디스크 파일) 분할하여 저장하는 데이터베이스 영속성 설계 기법입니다. 사용자는 하나의 테이블을 조회하는 것처럼 느끼지만, DBMS 내부에서는 물리적으로 분리된 구역에서 데이터를 관리합니다.

2) 페이지네이션(Pagination)이란?

조회 결과로 나올 수 있는 수만 건의 데이터 전체를 한 번에 어플리케이션 메모리에 로드하거나 화면에 전달하지 않고, 유저가 요청한 특정 페이지에 해당하는 데이터(예: 10건, 20건)만 구간을 잘라서 부분 조회하는 쿼리 기술입니다.

2. 파티션(물리적 분리)과 페이지네이션(전략적 데이터 제한)의 메커니즘

1) 파티션은 물리적 분리로 확실한 컴퓨팅 자원 절약

파티션의 본질은 파티션 프루닝(Partition Pruning)에 있습니다. 쿼리의 WHERE 조건에 파티션 키(예: 생성일자)가 포함되면, DBMS 쿼리 옵티마이저는 해당 조건에 맞지 않는 나머지 물리 디스크 공간을 스캔 대상에서 아예 제외합니다.

  • 무의미한 디스크 I/O를 원천 차단하므로 CPU, 메모리, 디스크 탐색 비용 등 데이터베이스 서버의 전체적인 컴퓨팅 자원을 확실하게 절약합니다.

2) 페이지네이션은 전략적으로 데이터를 제한하여, 과도한 컴퓨팅 자원 트랜스퍼를 제한

페이지네이션은 데이터베이스 디스크 공간을 아끼는 것이 아니라, 네트워크 파이프라인과 어플리케이션 서버의 자원을 보호하는 전략적 제한입니다. 만약 100만 건의 데이터를 한 번에 조회하면 DB 서버에서 어플리케이션 서버로 데이터를 전송하는 동안 네트워크 트래픽 오버헤드가 발생하고, 어플리케이션 메모리(Java Heap 등)가 순간적으로 팽창하여 시스템이 다운될 수 있습니다. 이를 건 단위로 제한하여 안전성을 확보합니다.

OFFSET이 커질수록 성능이 점점 느려지는 원인

RDBMS의 OFFSET 기반 페이징은 데이터를 바로 점프해서 읽는 것이 아니라, 처음부터 OFFSET + LIMIT 만큼의 데이터를 일단 순차적으로 다 스캔합니다.

예를 들어 LIMIT 10 OFFSET 500000인 경우, DB 내부에서는 50만 10건의 데이터를 디스크에서 다 읽어 올린 뒤, 앞의 50만 건을 메모리에서 버리는(Drop) 무모한 연산을 수행합니다. 이 때문에 뒤 페이지로 갈수록 스캔 성능이 기하급수적으로 떨어집니다.

이미지 불러오는 중
image

3. 파티셔닝과 적절한 페이지네이션의 조합 필요

대규모 엔터프라이즈 시스템에서는 파티셔닝을 통해 DB 디스크 스캔 범위를 물리적으로 줄이고, 페이지네이션을 통해 최종 전송 데이터의 양을 조절하는 상호보완적 설계가 필수적입니다.

실무에서 적용 가능한 파티셔닝과 페이지네이션 조합 시나리오

가장 대표적인 실무 사례인 '대규모 이커머스 주문 이력 시스템'을 기준으로 조합 전략을 구성할 수 있습니다. 한 테이블에 데이터가 1억 건 이상 쌓이는 환경입니다.

1단계: 파티셔닝 전략 (물리적 분리)

주문 테이블의 특성상 유저는 주로 '최근 주문 이력'을 조회하며, 과거 데이터는 정산이나 통계 목적으로만 쓰입니다. 따라서 주문일자(order_date) 컬럼을 기준으로 월별(Monthly) Range 파티션을 구성합니다.

  • 유저가 "2026년 6월 주문 내역"을 조회하는 순간, DB는 2026년 6월 파티션 디스크 파일만 열어봅니다. 나머지 수년 치 데이터가 저장된 물리 파일은 건드리지 않으므로 조회 범위가 1억 건에서 수십만 건으로 줄어듭니다.

2단계: No-Offset 페이지네이션 전략 (전략적 데이터 제한)

앞서 언급한 OFFSET의 한계를 극복하기 위해, 실무에서는 인덱스를 활용한 No-Offset(커서 기반) 페이지네이션을 파티션 테이블 위에 얹어서 쿼리를 수행합니다. 이전 페이지의 마지막 아이템 ID를 조건문으로 걸어 스캔 시작 위치를 제한하는 방식입니다.

실무 적용 최종 SQL 조합 예시

sql
-- 사용자가 2026년 6월 주문 내역의 '다음 페이지'를 요청했을 때의 쿼리
SELECT order_id, user_id, product_name, order_date
FROM orders
WHERE order_date BETWEEN '2026-06-01' AND '2026-06-30'  -- [1] 파티션 프루닝 발동: 26년 6월 디스크만 매핑
  AND order_id < 148590                                -- [2] No-Offset 커서: 앞선 50만 건을 스캔하지 않고 인덱스로 즉시 점프
ORDER BY order_id DESC
LIMIT 20;                                              -- [3] 최종 20건만 어플리케이션으로 전송

효과

  • 파티셔닝의 효과: 1억 건 중 2026년 6월에 해당하는 구역으로만 검색 대상을 좁혀 전체 덤프 부하를 차단합니다.
  • No-Offset 페이징의 효과: 해당 달의 데이터가 아무리 많아도, OFFSET 없이 인덱스 스캔 후 즉시 20건만 잘라내므로 첫 페이지를 열 때와 마지막 페이지를 열 때의 속도가 $O(1)$ 수준으로 동일하게 유지됩니다.
DISCUSSION

댓글

GitHub 계정으로 의견이나 질문을 남길 수 있습니다.

댓글 불러오는 중