refactor: 데이터베이스 성능 최적화

[mete0rfish]

🔨 요구 범주

📖 내용

1. N+1 문제 해결
   Fetch Join 시 문제점
2. 인덱싱
3. 트랜잭션
4. 동적 쿼리
5. 성능 측정을 어떻게 할 것인가?

• Explain Analyze
• Spring AOP

🚧 작업 목록

• 작업 1
• 작업 2
• 작업 3

🔗 관련 링크

�

[mete0rfish]

@LEEDONGH00N
동적 쿼리를 사용할 이유가 있을까요? 동적 쿼리 적용 시, 가독성 외에 성능적으로 이점이 있을까요??

[LEEDONGH00N]

@mete0rfish
성능 상의 이점은 없습니다. 오히려 성능은 정적 쿼리가 더 좋을 수 있습니다. 하지만 쿼리가 복잡해질수록, 즉 조건이 많이 붙을수록 말 그대로 쿼리를 동적으로 작성이 가능한 이점이 있습니다.

저희 프로젝트에서 모든 쿼리를 동적 쿼리로 수정하진 않을 겁니다. 비교적 간단한 쿼리들은 JpaRepository 인터페이스를 활용할 것이고, 필요하다면 직접 쿼리를 정의해 사용할 것이고, 이미 작성된 것도 있습니다. 하지만 제가 생각한 특정 기능을 가능케 하는 쿼리들만 동적 쿼리로 만들고 싶습니다. 예를 들어 저희는 도면 카테고리 검색에서 1차 카테고리, 2차 카테고리로 검색을 하는데, 어떤 경우엔 1차 카테고리만 존재하고, 어떤 경우엔 2차 카테고리만 존재하는데, 만약 이를 정적 쿼리로만 만든다면 모든 경우마다 쿼리를 정의해줘야 합니다. 동적 쿼리를 만든다면 값이 없을 땐 해당 조건에 대한 where 절을 붙히지 않게 하는 방법 등을 사용해 좀 더 유연한 쿼리를 작성할 수 있습니다.

추가적으로 제가 생각했을 땐 정적, 동적 쿼리를 같이 사용하면 더 좋을 것 같은데, 이를 위해선 Repository가 JpaRepository와 커스텀Repository를 extend하도록 바꿔야합니다.

위 그림처럼 정적 쿼리는 기존에 사용하던 인터페이스에 작성을 하고, 동적 쿼리는 커스텀Repository에 메서드를 정의하고, 구현 클래스에서 구현 로직을 작성한 후 해당 도메인의 Repository 인터페이스가 JpaRepository와 커스텀Repository를 상속하는 방법을 사용하려 합니다(인터페이스는 다중 상속이 가능).

아래는 제가 생각한 정적, 동적 쿼리의 장단점입니다.

방식	사용 추천 상황	장점	단점
정적 쿼리	🔹 검색 조건이 항상 고정 🔹 성능 최적화가 중요	✅ 빠르고 효율적 ✅ 캐싱 가능 ✅ 유지보수 용이	❌ 조건이 많아지면 쿼리 개수가 늘어날 수 있음
동적 쿼리	🔹 검색 조건이 자주 변함 🔹 필터링 조건이 유동적	✅ 조건 추가 가능 ✅ 불필요한 조건 제거 가능	❌ 성능 최적화가 어렵고 코드 복잡

📌 정적 쿼리는 단순한 경우에 사용하고, 조건이 자주 변경되는 경우 동적 쿼리를 활용하는 것이 좋음
📌 QueryDSL이 가장 유지보수성이 뛰어나므로, 동적 쿼리가 많다면 추천

[mete0rfish]

@LEEDONGH00N
참고할만한 레퍼런스가 있을까요??

[mete0rfish]

테스트

JOIN과 Subquery의 속도 차이

Important

데이터 1,000,000건을 기준으로 테스트 됐습니다.

기존 2차 카테고리 검색 쿼리의 경우, Blueprint와 SecondCategory를 서브쿼리로하여 검색한다. 일반적으로 서브쿼리보다 Join이 비용이 더 적다고 알고 있어 쿼리를 수정해보았다.

    @Query(value = """
        SELECT b FROM Blueprint b WHERE b.secondCategory = :second
        AND b.categoryId = (SELECT f.id FROM FirstCategory f WHERE f.name = :first)
        AND b.inspectionStatus = :status
       """)
    Page<Blueprint> findAllBySecondCategory(@Param("first") String firstCategory, @Param("second") String secondCategory, @Param("status") InspectionStatus status, Pageable pageable);

@Query(value = """
        SELECT b FROM Blueprint b JOIN FETCH FirstCategory f
        ON b.categoryId = f.id
        WHERE 
            b.secondCategory = :second
            AND f.name = :first
            AND b.inspectionStatus = :status
       """)

설명	응답시간	스캔 방식
JOIN	340	Table Scan
SubQuery	408	Inner Hash Join

결론적으로 Join이 성능적으로 더욱 우수하였다. 그 이유는 JOIN 키(category_id)가 인덱싱되어 있지 않아, Blueprint와 FirstCategory에 대한 Table Scan을 각각 수행 후 join을 또 한번 실행하기 때문이라고 추정된다.
따라서, 이를 해결하기 위해 blueprint 내부에 인덱싱을 도입하여 이를 해결하기로 결정했다.

인덱스 적용

먼저 1차 카테고리 검색의 경우 아래 쿼리가 수행된다.

    SELECT * FROM blueprint
    WHERE
        (is_deleted = 0) 
        AND category_id=? 
        AND second_category=? 
        AND inspection_status=? 
    ORDER BY id desc 
    LIMIT ?, ?

    SELECt count(id) FROM blueprint
    WHERE
        (is_deleted = 0) 
        AND category_id=? 
        AND second_category=? 
        AND inspection_status=? 

따라서, 커버링 인덱스를 통해 category_id와 second_category, inspection_status, is_deleted를 포함하도록 생성한 후 테스트를 진행했다.

@Index(name = "idx_blueprint_second_category", columnList = "categoryId, secondCategory, inspectionStatus, isDeleted, id DESC"),

인덱스 적용 전

인덱스 적용 후

결론적으로 637ms에서 473ms로 약 34% 향상시킬 수 있었다.

count 쿼리 최적화

현재 카테고리 검색의 경우, 인피니티 스크롤이 아닌 페이지 방식을 뷰에서 채택하고 있다. 따라서, Slice를 이용하여 count 쿼리를 수행시키지 않는 방법을 적용하는게 쉽지 않다. count 쿼리를 직접 지정하여 인덱스를 탈 수 있도록 제공해봤다.

count 인덱스 생성

// 인덱스
@Index(name = "idx_blueprint_count", columnList = "id, inspectionStatus, isDeleted")

// count Query
countQuery = "SELECT count(b.id) FROM Blueprint b WHERE b.inspectionStatus = :status"

Count 쿼리에서 사용할 수 있도록 id를 커버링 인덱스하여 인덱스를 지정했다.
결론적으로 별 차이가 없었다.

그 이유는 간단하다. InspectionStatus와 is_deleted는 거의 모든 데이터가 'PASSED'와 false로 지정되어 있어 인덱스를 사용해도 극적인 성능 개선이 보이지 않는다. 오히려 인덱스 생성으로 인한 저장 리소스 소모가 있다고 판단했다. 따라서, countQuery에 대한 별도의 인덱싱은 수행하지 않기로 결정했다.

결론

1. 카테고리 검색에서 사용할 수 있도록 커버링 인덱스를 도입했다.
2. countQuery는 불가피하게 사용해야 한다.
3. countQuery에 대한 인덱스는 극적인 성능 향상이 없고, 오히려 저장공간을 소모하기에 좋은 방법은 아니라고 판단한다.

[PlusUltraCode]

Filter 에서 Member를 한번 조회시 Member ,cart의 쿼리가 발생하는 N+1문베와 Member 자체가 2번 조회되는 문제 해결

해당 관련 PR 링크입니다.

@OnetoOne 을 사용시 분명 FetchType.LAZY를 설정했음에도 불구하고 cart가 계속 조회되는 문제를 해결했습니다.
자세한 내용은 PR에 적었습니다.!!

@OnetoOne 의 히든 N+1 오류??를 발견한 느낌입니다. 다들 한번씩 들어가서 해당 블로그 링크도 달아놨습니다.
같이 논의해보면 좋을거 같아요!!

헤당 오류를 고치면서 Hibernate가 어떻게 프록시를 생성하는지 깊이 이해했습니다. 많은 도움이 될거 같아요 : )