페이지네이션 가이드라인

GitLab에서 데이터를 페이지네이션하는 현재 기능 개요와 PostgreSQL을 사용하는 페이지네이션 모범 사례를 설명합니다.

이 문서는 GitLab에서, 특히 PostgreSQL에서 데이터를 페이지네이션하는 현재 기능의 개요와 모범 사례를 제공합니다. 페이지네이션이 필요한 이유 # 페이지네이션은 하나의 웹 요청에서 너무 많은 데이터를 로드하지 않기 위한 일반적인 기법입니다. 보통 레코드 목록을 렌더링할 때 발생합니다. 대표적인 시나리오는 UI에서 부모-자식 관계(has many)를 시각화하는 경우입니다. 예시: 프로젝트 내 이슈 목록 표시 프로젝트 내 이슈 수가 늘어날수록 목록이 길어집니다. 목록을 렌더링하기 위해 백엔드는 다음을 수행합니다. 데이터베이스에서 레코드를 로드합니다. 보통 특정 순서로 로드합니다. Ruby에서 레코드를 직렬화합니다. Ruby(ActiveRecord) 객체를 빌드한 다음 JSON 또는 HTML 문자열을 빌드합니다. 브라우저로 응답을 반환합니다. 브라우저가 콘텐츠를 렌더링합니다. 콘텐츠 렌더링 방식은 두 가지입니다. HTML: 백엔드가 렌더링을 처리합니다(HAML 템플릿). JSON: 클라이언트(클라이언트 측 JavaScript)가 페이로드를 HTML로 변환합니다. 긴 목록을 렌더링하면 프론트엔드와 백엔드 성능 모두에 큰 영향을 줄 수 있습니다. 데이터베이스가 디스크에서 많은 데이터를 읽습니다. 쿼리 결과(레코드)는 결국 Ruby 객체로 변환되어 메모리 할당이 늘어납니다. 응답이 크면 사용자 브라우저로 전송하는 데 시간이 더 걸립니다. 긴 목록을 렌더링하면 브라우저가 멈출 수 있습니다(나쁜 사용자 경험). 페이지네이션을 사용하면 데이터가 동일한 크기의 조각(페이지)으로 나뉩니다. 첫 방문 시 사용자는 제한된 수의 항목(페이지 크기)만 받습니다. 사용자는 앞으로 페이지를 이동해 더 많은 항목을 볼 수 있으며, 이때 새로운 HTTP 요청과 새로운 데이터베이스 쿼리가 발생합니다. 페이지네이션 일반 가이드라인 # 올바른 접근 방식 선택 # 페이지네이션, 필터링, 데이터 조회는 데이터베이스가 처리하도록 맡깁니다. 백엔드의 인메모리 페이지네이션(Kaminari의 paginate_array )이나 프론트엔드(JavaScript) 페이지네이션은 레코드가 수백 개 수준이면 동작할 수 있습니다. 애플리케이션 제한을 정의하지 않으면 상황이 빠르게 통제를 벗어납니다. 복잡성 줄이기 # 페이지에 레코드를 나열할 때 추가 필터와 여러 정렬 옵션을 함께 제공하는 경우가 많습니다. 이는 백엔드 측 복잡성을 크게 높입니다. MVC 버전에서는 다음을 고려합니다. 정렬 옵션 수를 최소한으로 줄입니다. 필터 수(드롭다운 목록, 검색창)를 최소한으로 줄입니다. 정렬과 페이지네이션을 효율적으로 만들려면 각 정렬 옵션마다 최소 두 개의 데이터베이스 인덱스(오름차순, 내림차순)가 필요합니다. 필터 옵션(상태별 또는 작성자별)을 추가하면 좋은 성능을 유지하기 위해 더 많은 인덱스가 필요할 수 있습니다. 인덱스는 공짜가 아니며 UPDATE 쿼리 시간에 큰 영향을 줄 수 있습니다. 모든 필터와 정렬 조합을 성능적으로 만족시킬 수는 없으므로, 사용 패턴을 기준으로 성능을 최적화합니다.