페이지네이션 가이드라인

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

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