[Querydsl] Pagination 성능 개선 part1.PageableExecutionUtils

목차

• 기존 : QueryDSL의 페이징
• 개선 : PageableExecutionUtils : new PageImpl()의 count 쿼리 개선
• Test Case
  1. Test case 1. 페이지 사이즈 20 / 총 content 8개 / 첫 번째 페이지 호출
  2. Test case 2. 페이지 사이즈 5 / 총 content 8개 / 두번째 페이지 호출
  3. Test case 3. 페이지 사이즈 3 / 총 content 8개 / 두번째 페이지 호출 (총 3개의 페이지 존재)
• 결론

 

(기존) QueryDSL의 페이징

보통 QueryDsl (이하 qdsl)에서 페이징 할 땐 new PageImpl()을 사용했습니다.

이름대로 Page 인터페이스의 구현체이며, 동시에 Chunk 인터페이스의 구현체입니다. (여기선 중요한 게 아니니 패스)

- content : 페이징을 적용한(e.g. offset, limit) 쿼리 결과
- total : 페이징을 적용하지 않은 전체 결과의 크기

 

content 인자

content 인자는 JpaQuery의 fetch() 혹은 fetchResults() 결과 값을 의미합니다. fetchResults()는 Deprecated 됐으니 fetch()를 사용하는 것을 권장합니다.

 

아래 왼쪽은 content 인자의 예시입니다.

.offset() .limit() 을 사용하여 페이징 적용한 것을 볼 수 있습니다.

 

 

total 인자

오른쪽은 total 인자에 들어갈 long 타입의 count입니다.

위의 content 쿼리와 동일한 where 절을 적용하지만, offset, limit을 적용하지 않은 결과의 수를 출력합니다. 쿼리 최적화를 위해 불필요한 join clause도 제거했습니다.

 

new PageImpl() 정리

new PageImpl()은 총 두 번의 쿼리를 실행하여 페이징을 적용한다는 것을 알 수 있습니다.

 

---

 

(개선) PageableExecutionUtils : new PageImpl()의 count 쿼리 개선

PageableExecutionUtils를 사용하면 기존 PageImp을 사용할 때 보다 성능 최적화를 할 수 있습니다. PageableExecutionUtils는 어떤 특징을 가지는지, 어떤 식으로 쿼리 최적화를 할 수 있는지 알아보겠습니다.

 

공식문서에서 PageableExecutionUtils 설명입니다.

from Docs

 

하이라이트 밑줄을 의역하면 "데이터 쿼리가 count 쿼리보다 비용이 덜 든다고 가정"이라 하네요.

뜻이 명확하지 않은데, 우리의 최고 성능 번역기(아님)에게 물어보겠습니다.

 

의역과 크게 차이나지 않습니다, 이런 나 chat gpt에게 비빌수 있을지도..?

 

정리하자면, PageableExecutionUtils을 사용하면 단순 new PageImpl()을 사용했을 때 보다 성능 최적화 이점이 있습니다.

PageableExecutionUtils 클래스는 내부에 getPage()라는 단 하나의 (정적) 메서드를 가집니다.

 

PageableExecutionUtils.getPage()

public static <T> Page<T> getPage(List<T> content, Pageable pageable, LongSupplier totalSupplier) {

    Assert.notNull(content, "Content must not be null");
    Assert.notNull(pageable, "Pageable must not be null");
    Assert.notNull(totalSupplier, "TotalSupplier must not be null");

    if (pageable.isUnpaged() || pageable.getOffset() == 0) {

        if (pageable.isUnpaged() || pageable.getPageSize() > content.size()) {
            return new PageImpl<>(content, pageable, content.size());
        }

        return new PageImpl<>(content, pageable, totalSupplier.getAsLong());
    }

    if (content.size() != 0 && pageable.getPageSize() > content.size()) {
        return new PageImpl<>(content, pageable, pageable.getOffset() + content.size());
    }

    return new PageImpl<>(content, pageable, totalSupplier.getAsLong());
}
}

 

아래 필기를 보면 더 쉽게 이해할지도? 아닐지도?

 

 

위 필기를 정리하자면

1. 첫 번째 페이지이면서 content 크기가 한 페이지의 사이즈보다 작을 때 (ex, content:3개, page 크기: 10)

2. 마지막 페이지일 때 (getOffset이 0이 아니면서, content 크기가 한 페이지의 사이즈보다 작을 때)

totalSupplier 대신 content의 size와 offset 값으로 total 값을 대신합니다.

 

PageableExecutionUtils.getPage() 내부에선 결국 new PageImpl()을 호출하고 있습니다. 즉 new PageImpl()을 한번 더 추상화했다고 볼 수 있습니다.

 

기존 new PageImpl()와 getPage()의 차이는 세 번째 인자만 LongSupplier totalSupplier 로 변경됐다는 것이죠.

long total 인 primitive 인자를 LongSupplier totalSupplier 함수형 인터페이스가 대신합니다.

원시형 타입 대신 함수형 인터페이스를 받을 때 생기는 이점은 무엇일까요?

 

결과론적인 얘기지만 현재 상황에선, 호출 시점을 지연시킬 수 있다고 생각합니다. 어떤 함수의 호출 시점이요? count 쿼리의 호출 시점입니다. 기존 pageImpl()에선 count 값을 세 번째 인자로 넣기 위해 count 쿼리를 필수로 호출했지만 PageableExecutionUtils.getPage() 에선 count 쿼리를 실행하기 전인 함수형 인터페이스를 인자로 받고 있습니다.

 

노란색 하이라이트를 보면, new PageImpl()의 세번째 인자로 totalSupplier 대신 content.size() , pageable.getOffset() 값을 받습니다. 즉 count 쿼리를 실행하지 않아 불필요한 쿼리를 날리지 않습니다. 기존 pageImpl에서 두 번의 쿼리를 날리던 것에 비해 성능 최적화를 이룰 수 있습니다.

 

 

샘플코드를 보면서 확인해 보겠습니다.

@RequiredArgsConstructor
public class BookmarkRepositoryImpl implements BookmarkRepositoryCustom {

    private final JPAQueryFactory query;
    private final QFolder qFolder = QFolder.folder;
    private final QBookmark qBookmark = QBookmark.bookmark;

    @Override
    public Page<BookmarkResponse> findBookmarksWithFolderId(Long userId, Pageable pageable) {

        List<BookmarkResponse> fetch = query.select(new QBookmarkResponse(qBookmark, qFolder.id))
            .from(qBookmark)
            .where(condition(userId))
            .offset(pageable.getOffset())
            .limit(pageable.getPageSize())
            .fetch();

        JPAQuery<Long> count = query.select(qBookmark.count())
            .from(qBookmark)
            .where(condition(userId));

        return PageableExecutionUtils.getPage(fetch, pageable, count::fetchOne);  // 여기
    }
}

 

PageableExecutionUtils.getPage()의 세 번째 인자에서, () -> count.fetchOne() 람다식을 인자로 받습니다.

즉 getPage() 메서드 내부에서 해당 람다식을 호출하기 전까지 count 쿼리는 실행되지 않습니다.

 

위에서 totalSupplier 함수형 인터페이스가 호출되지 않는 조건을 다시 보겠습니다.

1. 첫 번째 페이지이면서 content 크기가 한 페이지의 사이즈보다 작을 때 (ex, content:3개, page 크기: 10)

2. 마지막 페이지일 때 (getOffset이 0이 아니면서, content 크기가 한 페이지의 사이즈보다 작을 때)

 

test case 마다 API를 호출해 확인해 보겠습니다.

---

 

Test Case

 

Test case 1. 페이지 사이즈 20 / 총 content 8개 / 첫 번째 페이지 호출 

 

API 호출 

Debugger

칼같이 조건문에 걸리면서 content.size()를 세 번째 인자로 받는 것을 확인할 수 있습니다.

 

결과

{
    "content": [
        {
            "id": 1,
            "url": "www.google.com",
            "name": "바드 떡락 ㅠ",
            "folderId": 3
        },
        
      ...
      
        {
            "id": 17,
            "url": "chat.openai.com",
            "name": "지피티야 글좀 써다오",
            "folderId": 1
        },
        {
            "id": 19,
            "url": "www.google.com",
            "name": "백엔드",
            "folderId": 1
        }
    ],
    "pageable": {
        "sort": {
            "empty": true,
            "unsorted": true,
            "sorted": false
        },
        "offset": 0,
        "pageNumber": 0,
        "pageSize": 20,
        "paged": true,
        "unpaged": false
    },
    "last": true,
    "totalPages": 1,
    "totalElements": 8,
    "first": true,
    "size": 20,
    "number": 0,
    "sort": {
        "empty": true,
        "unsorted": true,
        "sorted": false
    },
    "numberOfElements": 8,
    "empty": false
}

 

실행된 쿼리

조회 쿼리만 실행되고, count 쿼리는 실행되지 않는 걸 확인할 수 있습니다.

 

 

Test case 2. 페이지 사이즈 5 / 총 content 8개 / 두 번째 페이지 호출 

API 호출

 

Debugger

조건문에 걸리면서 offset 크기와 content 사이즈를 더하여 totalCount를 대신하는 것을 확인할 수 있습니다. 

 

실행된 쿼리

Test case1과 마찬가지로 조회 쿼리만 실행되고, count 쿼리는 실행되지 않습니다.

 

 

Test case 3.  페이지 사이즈 3 / 총 content 8개 / 두 번째 페이지 호출  (총 3개의 페이지 존재)

맨 앞/뒤 페이지를 조회한 case 1, 2와 달리 Test Case3는 중간 페이지를 조회합니다.

 

API 호출

Debugger

이전 테스트 케이스와 달리 totalSupplier.getAsLong()을 호출합니다.

이전에는 count 쿼리가 실행되지 않은 것과 달리, 이번 테스트케이스에서는 count 쿼리가 실행될 것을 예상할 수 있습니다.

 

실행된 쿼리

짜잔

조회 쿼리와 count 쿼리 모두 실행되는 것을 확인할 수 있습니다.

 

 

Testcase 4. PageableExecutionUtils.getPage() 대신 new PageImpl() 바로 사용

pageImpl을 바로 호출할 땐 어떨까요?

첫 페이지와 마지막 페이지를 조회했음에도 두 개의 쿼리가 모두 실행됩니다.

즉 PageableExecutionUtils을 사용해 중간 페이지를 조회한 것과 동일한 결과가 출력됩니다.

 

---

 

결론

이로써 PageableExecutionUtils.getPage()를 사용하면 불필요한 count 쿼리가 실행되는 케이스를 줄일 수 있음을 알 수 있었습니다. 첫 번째 페이지를 조회하거나 마지막 페이지를 조회할 때만큼은 불필요한 count 쿼리가 실행되지 않겠네요.

 

사용자가 첫 페이지에서 머무는 경우가 많은 서비스라면 성능 최적화가 잘 이루어질 것이라 예상해 봅니다.

추가로 제가 만들고자 하는 서비스는 페이징을 목차형으로 구현하지 않고 스크롤 형식으로 구현하고 있습니다.

 

이런 경우에는 noOffset을 사용하여 추가 성능개선을 할 수 있는데 다음 포스트에서 더 다뤄보도록 하겠습니다. 안뇽!