GraphQL 페이지네이션

GitLab GraphQL API에서 사용하는 오프셋 페이지네이션과 키셋 페이지네이션의 원리, 구현 방법, 테스트 방법을 설명합니다.

페이지네이션 유형 # GitLab은 두 가지 주요 페이지네이션 방식을 사용합니다: 오프셋(offset) 페이지네이션과 키셋(keyset) (커서 기반이라고도 함) 페이지네이션입니다. GraphQL API는 주로 키셋 페이지네이션을 사용하며, 필요한 경우 오프셋 페이지네이션으로 대체합니다. 성능 고려사항 # 자세한 내용은 일반 페이지네이션 가이드라인 섹션 을 참고하세요. 오프셋 페이지네이션 # 이것은 가장 일반적인 전통적인 페이지 단위 페이지네이션으로, GitLab 전반에 걸쳐 널리 사용됩니다. 페이지 하단 근처에 있는 페이지 번호 목록을 통해 확인할 수 있으며, 선택하면 해당 결과 페이지로 이동합니다. 예를 들어 Page 100 을 선택하면 백엔드에 100 을 전송합니다. 각 페이지에 20개의 항목이 있다고 가정하면, 백엔드는 20 * 100 = 2000 을 계산하고, 처음 2000개의 레코드를 오프셋(건너뛰기)한 후 다음 20개를 가져오도록 데이터베이스를 조회합니다. page number * page size = where to find my records 이 방식에는 몇 가지 문제점이 있습니다: 성능 문제. 페이지 100을 조회하면(오프셋 2000) 데이터베이스가 테이블을 해당 특정 오프셋까지 스캔한 후 다음 20개의 레코드를 가져와야 합니다. 오프셋이 증가할수록 성능이 급격히 저하됩니다. 자세한 내용은 The SQL I Love <3. Efficient pagination of a table with 100M records 를 참고하세요. 데이터 안정성 문제. 페이지 100의 20개 항목(오프셋 2000)을 가져오면 GitLab은 해당 20개의 항목을 표시합니다. 그런데 페이지 99 이전에서 레코드가 삭제되거나 추가되면, 오프셋 2000의 항목들이 다른 항목들로 바뀝니다. 심지어 페이지네이션 도중 목록이 계속 변경되어 일부 항목을 건너뛰는 상황이 발생할 수도 있습니다. 자세한 내용은 Pagination: You're (Probably) Doing It Wrong 을 참고하세요. 키셋 페이지네이션 # 특정 레코드가 있을 때, 그 다음에 오는 것을 계산하는 방법을 알면 데이터베이스에서 해당 특정 레코드들을 조회할 수 있습니다. 예를 들어, 생성 날짜순으로 정렬된 이슈 목록이 있다고 가정합니다. 페이지의 첫 번째 항목이 특정 날짜(예: 1월 1일)를 가지고 있다는 것을 안다면, 해당 날짜 이후에 생성된 모든 레코드를 요청하여 처음 20개를 가져올 수 있습니다. 많은 레코드가 삭제되거나 추가되더라도, 항상 그 날짜 이후의 것들을 요청하므로 올바른 항목을 가져올 수 있습니다. 아쉽게도, 1월 1일에 생성된 이슈가 20페이지인지 100페이지인지 쉽게 알 수 있는 방법은 없습니다. 키셋 페이지네이션의 장단점은 다음과 같습니다. 성능이 훨씬 뛰어납니다. 삭제나 삽입으로 인해 목록에서 레코드가 누락되지 않으므로, 최종 사용자에게 더 높은 데이터 안정성을 제공합니다. 무한 스크롤을 구현하는 데 가장 적합한 방식입니다. 프로그래밍과 유지보수가