쿼리 최적화 고민 (검색 제외)

[kyum-q]

쿼리 최적화 하면서 고민했던 방식들에 대해 기록한다.

[kyum-q]

템플릿 단건 조회

3번째 방법만 구현

방법1： Batch Fetching

TemplateTag에서 여러 태그를 조회하는 쿼리는 N+1 문제를 야기할 수 있다. 이를 해결하기 위해 @BatchSize 애너테이션을 사용하여 한 번에 여러 태그를 로드하도록 설정한다.

방법2 : 커버링 인덱스

현재 response에 사용되지 않는 modifiedAt, createdAt 등의 데이터도 조회하기 위해 인덱스만으로 데이터를 찾지 못하고 있다.
추후 개선이 필요하다면 해당 값들은 제거된 Dto를 받도록 개선할지 고민 중이다.

방법3: TemplateTag 조회 로직 변경 👍

Template의 Tag 목록 조회 / Tag 정보 조회 (ID별) 을 하나의 query로 변경

@Query("""
	SELECT t  
	FROM Tag t  
	JOIN TemplateTag tt ON t.id = tt.id.templateId  
	WHERE tt.template = :template
""")  
List<Tag> findAllByTemplate(Template template);

Template의 Tag 목록 조회

• Repository: TemplateTagJpaRepository
• Method: findAllByTemplate

select
    t1_0.id,
    t1_0.created_at,
    t1_0.modified_at,
    t1_0.name 
from
    tag t1_0 
join
    template_tag tt1_0 
        on t1_0.id=tt1_0.template_id 
where
    tt1_0.template_id=?

• 호출 횟수: 1회 (Template ID: 26377)

[kyum-q]

템플릿 삭제

1번 방법만 구현

방법 1: @Modifying을 이용한 삭제 쿼리 개선

템플릿들의 요소를 삭제하는 방법이 현재 deleteByTemplateId 여러번 실행하고 있다.

해당 부분을 한번의 쿼리로 모두 삭제하는 명령어로 변경한다.

@Modifying(clearAutomatically = true)

@Modifying을 사용해 해당 메서드가 데이터베이스의 데이터를 변경하는 쿼리임을 Spring Data JPA에 알릴 수 있다.

• 영속성 컨텍스트와 데이터 불일치 문제가 생길 수 있다.
  • 영속성 컨텍스트를 비워주는 작업을 도와주는 설정을 추가해야한다.
  • **@Modifying(clearAutomatically=true) 속성을 사용해 변경 후 자동으로 영속성 컨텍스트를 초기화
• 벌크 연산 시 사용
  • 벌크 연산은 데이터베이스에서 UPDATE, DELETE 시 대량의 데이터를 한 번에 처리하는 작업

참고 자료 : @Modifying 이란?

썸네일 삭제

@Modifying(clearAutomatically = true)
@Query("DELETE FROM Thumbnail t WHERE t.template.id in :templateIds")
void deleteByTemplateIds(List<Long> templateIds);

썸네일 삭제 (Template ID 기반)

• Repository: ThumbnailJpaRepository
• Method: deleteByTemplateIds

delete t1_0 
from
    thumbnail t1_0 
where
    t1_0.template_id in (?)

소스코드 삭제

@Modifying(clearAutomatically = true)  
@Query("DELETE FROM SourceCode s WHERE s.template.id in :templateIds")  
void deleteByTemplateIds(List<Long> templateIds);

소스코드 삭제 (Template ID 기반)

• Repository: SourceCodeJpaRepository
• Method: deleteByTemplateIds

delete sc1_0 
from
    source_code sc1_0 
where
    sc1_0.template_id in (?)

템플릿태그 삭제

@Modifying(clearAutomatically = true)  
@Query("DELETE FROM TemplateTag t WHERE t.template.id in :templateIds")  
void deleteAllByTemplateIds(List<Long> templateIds);

템플릿태그 삭제 (Template ID 기반)

• Repository: TemplateTagJpaRepository
• Method: deleteByTemplateIds

delete tt1_0 
from
	template_tag tt1_0 
where
    tt1_0.template_id in (?)

방법 2: 템플릿 삭제 시 삭제 권한을 확인해야할까?

현재는 템플릿 삭제 전에 템플릿 id로 템플릿 조회 후 템플릿 권한을 확인한 후 삭제한다.

해당 로직을 바로 템플릿 삭제 시, 다음 로직으로 변경하면 어떨까?

• id와 member 가 일치하는 게 있을 경우 삭제
• id와 member가 일치하는 게 없을 경우 아무일도 안남 (예외 처리 안남)

확인하지 않아도 된다면

AS-IS

Template template = templateRepository.fetchById(id);  
template.validateAuthorization(member);  
templateRepository.deleteById(id);

TO-BE

templateRepository.deleteByIdAndMember(id, member);

[kyum-q]

회원 정보 조회

인덱스 개선 사항

Member 테이블

• 인덱스 제안:
  • id, name
    • 이유: 커버링 인덱스 사용으로 속도 개선을 위해
    • 추가 여부: O, CREATE INDEX idx_member_id_name ON member (id, name);

쿼리 최적화

커버링 인덱스

커버링 인덱스 (Covering Index 혹은 Covered Index)

• 쿼리를 충족시키는 데 필요한 모든 데이터를 갖고 있는 인덱스
• SELECT, WHERE, ORDER BY, GROUP BY 등에 사용되는 모든 컬럼이 인덱스의 구성요소인 경우

멤버 ID로 해당 멤버 객체를 조회한다. 하지만 실상 해당 로직 이후 멤버 이름 외에는 사용되는 정보가 없다.

그래서 멤버를 조회하는 로직을 멤버 이름을 조회하는 로직으로 수정한다. 이를 통해 커버링 인덱스 이용하도록 변경해 쿼리 성능을 개선한다.

Before

After

BUT 개선 못함. 인터셉터에서 멤버 조회하기 때문~