[BE] refactor: 상품 목록 조회 api 성능 개선

[hanueleee]

Issue

• close [BE] 상품목록조회api 수정 및 개선 #669

✨ 구현한 기능

상품 목록 조회 Api 성능 개선

(기존)

• ReviewCount를 위해 Product와 Review Join
• Page반환
• reviewCount 기준 정렬로 인해 service에 분기 + repository에 메소드 2개

(1차 개선)

• ReviewCount 반정규화
• Page 대신 Slice 반환
  • 펀잇은 무한스크롤 방식이기 때문에 페이징에 대한 자세한 정보(ex. 총 페이지 수)가 필요없다.
  • Slice를 반환하여 hasNext(다음 페이지가 존재하는지)값만 넘기도록 수정
• 오프셋 페이징 -> 커서 페이징

SELECT
    p.id,
    p.name,
    p.price,
    p.image,
    p.average_rating,
    p.review_count
FROM product p
JOIN product p2
    ON p2.id = :lastProductId
WHERE
        p.category_id = 2 AND
        (
            (p.price = p2.price AND p.id < :lastProductId) OR
            p.price > p2.price
        )
ORDER BY p.price, p.id DESC
LIMIT 11;

(2차 개선) 인덱스

(3차 개선) 동적 쿼리 ???

📢 논의하고 싶은 내용

Pageable을 걷어내다보니 정렬조건에 따라 메소드가 무려 10개가 나옵니다.
동적쿼리를 위한 QueryDsl 도입이 시급!

🎸 기타

• X

⏰ 일정

• 추정 시간 :
• 걸린 시간 :

[github-actions]

Test Results

258 tests   258 ✔️  20s ⏱️
130 suites      0 💤
130 files        0 ❌

Results for commit 9d9008a.

♻️ This comment has been updated with latest results.

[hanueleee]

3-1 동적 쿼리 사용 X

service

repository

[hanueleee]

3-2 동적 쿼리 사용 (criteria + specification)

고민 과정

1. join

SELECT
    p.id, p.name, p.price, p.image, p.average_rating, p.review_count
FROM product p
JOIN product p2
    ON p2.id = :lastProductId
WHERE
        p.category_id = 2 AND
        (
            (p.price = p2.price AND p.id < :lastProductId) OR
            p.price > p2.price
        )
ORDER BY p.price, p.id DESC
LIMIT 11;

위와 같은 기존 쿼리를 살려서 join을 하고자 했으나,
p(product)와 p2(product) 사이의 연관관계가 없어서 specification을 통해 쿼리를 만들 수가 없었습니다.
specification에서 join을 사용하려면 엔티티간 연관관계가 존재해야함!! (엔티티 클래스에 매핑 추가)

2. subquery

SELECT
    p.id, p.name, p.price, p.image, p.average_rating, p.review_count
FROM product p
WHERE
        p.category_id = 2 AND
        (
            (p.price = (select price from product where id = :lastProductId) AND p.id < :lastProductId)
            OR p.price > (select price from product where id = :lastProductId)
        )
ORDER BY p.price, p.id DESC
LIMIT 11;

1)에서 Join을 하는 이유가 lastProduct의 price가 필요해서 였기 때문에,
subquery로도 해결은 가능합니다.
하지만 서브쿼리는 성능상 좋지않고 완전히 동일한 서브쿼리가 2번 나간다는 점에서 탈락!

3. findById로 price 가져오기

위 모든 행위의 이유는 딱 'lastProduct의 price가 필요'해서 -> 그냥 findById로 가져오는 건 어떨까?
우리가 사용하는 db는 mysql이고 innoDB이기 때문에 PK 기반 조회는 매우 빠를 것.
그러므로 일단 이 방법을 사용하기로 결정!
(전에 다같이 잠깐 논의했던대로 프론트에서 price를 넘겨주게 된다면 해당 로직 제거 가능)

결과

service

관련 커밋

[hanueleee]

3-3 API 개선 (count 쿼리 제거)

specification을 사용할 때에는 보통 JpaSpecificationExecutor를 쓴다.

3-2에는 페이징(limt)을 위해 pageable이 필요하기 때문에 저 3번째를 사용했었다.

Page를 반환값으로 하면 count쿼리가 계속 나감
-> 펀잇은 무한스크롤 방식이기 때문에 페이징에 대한 자세한 정보(ex. 총 페이지 수)가 필요없다
-> 반환값을 List로 하고 싶다

커스텀 레포지토리(BaseRepository)에 specification용 메소드 추가

• 기존에 pageable은 오직 limit을 위해 사용했었음 -> pageable 대신 size를 받아와 바로 세팅
• Page 대신 List를 반환

public List<T> findAllWithSpecification(final Specification spec, final int size) {
        final TypedQuery<T> query = getQuery(spec, Sort.unsorted());
        query.setMaxResults(size);

        return query.getResultList();
    }

관련 커밋

[wugawuga]

고생하셨습니다!

[70825]

간단한 것만 수정하면 될 것 같아요~
고생하셨습니다~

[Go-Jaecheol]

코멘트 몇 개 남겨두었습니다.
확인해주세요~~!~!

[Go-Jaecheol]

고생하셨어요~~