쿼리 튜닝 - 대용량 데이터를 포함하는 특정 컬럼 제외하고 조회

개요

Spring Data JPA 를 사용해서 DB 를 조회하면 지연 로딩으로 설정되어 있는 연관 관계 데이터를 제외하고 처음부터 모든 데이터 컬럼 값들을 불러온다. JPA 특정 상 처음에 모든 값들을 초기화 시키고 스냅샵을 기준으로 더티 체킹을 해야하기 때문이다. 하지만 readOnly = true일 경우는 더티체킹을 할 필요가 없고 원하는 값만 얻으면 되기 때문에 모든 값을 초기화해서 얻을 필요도 없다.

예를 들어 DocumentDB 와 같은 NoSQL을 사용하지 않고, RDB로 아티클 정보를 저장했다고 치자. 

 

@Entity
public class Article {
    @Id
    @GeneratedValue
    private Long id;

    private String title;

    @Column(columnDefinition = "TEXT")
    private String content; // 대량 데이터 (본문 내용)

    private String author;
}

 

아티클의 본문 내용은 길이를 예측할 수 없으니 SQL 자료형중에 많은 문자를 저장할 수 있는 TEXT 자료형을 가져야 한다.

이때 아티클 목록을 조회하기 위해서 간단하게 다음처럼 JPA 를 활용할 수 있다.

List<Article> articles = articleRepository.findAll();

 

아티클 리스트를 가공하여 리스폰스로 변경후 응답값으로 줄 수 있다. 매번 아무렇지 않게 다들 이렇게 사용할 것이다. 하지만 아무 생각 없이 그냥 사용했다간 메모리 낭비와 성능 저하를 일으킬 수 있다. 

SELECT id, title, content, author FROM articles;

 

 

위 방식대로 사용하면 모든 아티클마다 본문 내용을 가지고 있게 된다. 본문 내용은 다른 필드 보다 더 큰 데이터 양을 갖고 있고, 대용량 데이터는 그에 비례하여 높은 네트워크 대역폭과 불필요한 메모리 공간을 갖게 된다.

 

TEXT, BLOB처럼 데이터 크기가 큰 컬럼은 조회 비용이 높으므로, 쿼리 성능에 큰 영향을 줄 수 있다. 데이터베이스에서 모든 필드를 가져오지 않고, 필요한 데이터만 선택적으로 가져오는 것은 효율적인 자원 사용을 위해 중요한 튜닝 기법이다. 따라서 DTO를 사용하여 필요한 데이터만 조회하도록 설계를 바꿔 데이터 전송과 로딩 시간을 줄여주는 것이 좋다.

 

public class ArticleDTO {
    private Long id;
    private String title;
    private String author;

    public ArticleDTO(Long id, String title, String author) {
        this.id = id;
        this.title = title;
        this.author = author;
    }
}

 

필요한 값만 필드로 갖는 DTO를 만들어 준다.

@Query("SELECT new com.example.dto.ArticleDTO(a.id, a.title, a.author) FROM Article a")
List<ArticleDTO> findArticlesWithoutContent();

SELECT id, title, author FROM articles;

 

그리고 JPQL로 필요한 컬럼만 조회한다.

List<ArticleDTO> articles = articleRepository.findArticlesWithoutContent();

 

ORM 에 의해 테이블의 컬럼들은 DTO 의 필드에 알맞게 파싱된다. 대용량 데이터를 갖는 컬럼을 제외했으므로 전송되는 데이터 양이 줄어들고, 쿼리 실행 속도가 향상된다.

 

이렇게 DTO로 필요한 컬럼만을 갖는 쿼리 튜닝 방식은 다음과 같은 이점을 갖는다.

1. 데이터베이스 I/O 감소
   • TEXT 또는 BLOB 같은 대용량 데이터를 읽어들이는 비용을 절약할 수 있다.
2. 네트워크 전송량 감소
   • 불필요한 데이터를 애플리케이션으로 전송하지 않으므로 네트워크 부하가 줄어든다.
3. 애플리케이션 메모리 사용 최적화
   • 애플리케이션이 불필요한 데이터를 메모리에 로드하지 않으므로 메모리 사용량이 줄어든다.
4. 쿼리 실행 시간 단축
   • 데이터베이스가 처리해야 할 데이터 양이 줄어들어 쿼리 실행 시간이 단축된다.

 

하지만 모든 조회를 다 DTO를 써서 조회하는 게 항상 좋은 것은 아니다. 특정 경우에는 엔티티의 필드 내용을 모두 포함하여 조회하는 것이 더 나을 수 있다.

 

조회 시나리오를 따져봐서 추가 쿼리 발생 가능성이 없는 지 확인해야한다.

• 제외 했던 필드가 필요한 시점에서 다시 조회해야 하므로 추가 쿼리가 발생할 수 있다. (N+1 문제가 발생하지 않도록 주의)

또한 DTO 설계도 유의해야한다. DTO 클래스를 설계하고 유지보수해야 하므로, DTO 사용이 항상 간단하지 않을 수 있다.

 

DTO 설계

public class ChatRoomUserDTO {
    private Long chatRoomId;
    private String chatRoomName;
    private String userName;

    public ChatRoomUserDTO(Long chatRoomId, String chatRoomName, String userName) {
        this.chatRoomId = chatRoomId;
        this.chatRoomName = chatRoomName;
        this.userName = userName;
    }
}

@Query("SELECT new com.example.dto.ChatRoomUserDTO(cr.id, cr.name, u.name) " +
       "FROM ChatRoom cr JOIN cr.user u")
List<ChatRoomUserDTO> findChatRoomsWithUsers();

 

위와 같은 방식을 예로 들면 DTO 생성자를 통해서 조회가 일어나고 있다.

하지만 MyBatis 에서 클래스를 경로를 적는 것 같은 방식만 있는 건 아니다.

 

1. 스프링 데이터 JPA의 기본 규칙 활용

Spring Data JPA에서는 반환 타입으로 DTO 클래스를 지정하면, 자동으로 패키지 경로를 감지한다. DTO 클래스가 같은 패키지에 있거나 리포지토리와 동일한 모듈 내에 존재할 경우 패키지 경로를 생략할 수 있다.

ChatRoomUserDTO가 리포지토리와 동일한 패키지이거나, 클래스 경로를 Spring Data JPA가 찾을 수 있는 범위에 있어야 한다.

// ChatRoomUserDTO 클래스가 같은 패키지에 있다고 가정
@Query("SELECT new ChatRoomUserDTO(cr.id, cr.name, u.name) " +
       "FROM ChatRoom cr JOIN cr.user u")
List<ChatRoomUserDTO> findChatRoomsWithUsers();

 

 

위 방식은 Spring Data JPA와의 자연스러운 통합하여 딱히 추가 설정도 필요없고, DTO와 비즈니스 로직의 의도를 명확히 구분할 수 있다. 또한 DTO는 독립적인 POJO로 동작하기 때문에 단위 테스트가 용이하다. DTO 클래스에 추가 필드를 쉽게 확장할 수 있다.

 

2. Projection 인터페이스 사용

Spring Data JPA에서 Projection을 사용하면 DTO 객체를 직접 생성하지 않고도 특정 필드만 조회하여 매핑할 수 있다.

public interface ChatRoomUserProjection {
    Long getChatRoomId();
    String getChatRoomName();
    String getUserName();
}

 

쿼리에서 인터페이스 반환

Spring Data JPA는 쿼리 결과를 Projection 인터페이스에 맞게 자동으로 매핑한다.

@Query("SELECT cr.id AS chatRoomId, cr.name AS chatRoomName, u.name AS userName " +
       "FROM ChatRoom cr JOIN cr.user u")
List<ChatRoomUserProjection> findChatRoomsWithUsers();


List<ChatRoomUserProjection> results = chatRoomRepository.findChatRoomsWithUsers();

 

장점으로는 DTO 객체를 명시적으로 생성하지 않아도 된다. 하지만 Projection은 읽기 전용으로, DTO에 로직이나 변환 작업이 필요한 경우 적합하지 않다.

 

3. 네이티브 쿼리와 @SqlResultSetMapping 활용

DTO의 생성자 호출을 피하고, 네이티브 쿼리와 @SqlResultSetMapping을 사용하여 간접적으로 DTO로 매핑할 수 있다. JPA 표준 기능으로, 일반 JPA에서 네이티브 쿼리의 결과를 DTO나 엔티티에 매핑할 때 사용한다. Spring Data JPA에서는 직접적으로 연동되지 않으며, 사용하려면 EntityManager를 통해 네이티브 쿼리를 실행해야 한다. EntityManager.createNativeQuery() 메서드에서 쿼리와 @SqlResultSetMapping 이름을 연결하여 매핑을 수행한다.

public class ChatRoomUserDTO {
    private Long chatRoomId;
    private String chatRoomName;
    private String userName;

    public ChatRoomUserDTO(Long chatRoomId, String chatRoomName, String userName) {
        this.chatRoomId = chatRoomId;
        this.chatRoomName = chatRoomName;
        this.userName = userName;
    }
}

 

@Entity
@SqlResultSetMapping(
    name = "ChatRoomUserMapping",
    classes = @ConstructorResult(
        targetClass = ChatRoomUserDTO.class,
        columns = {
            @ColumnResult(name = "chatRoomId", type = Long.class),
            @ColumnResult(name = "chatRoomName", type = String.class),
            @ColumnResult(name = "userName", type = String.class)
        }
    )
)
public class ChatRoom {
    @Id
    @GeneratedValue
    private Long id;

    private String name;

    //다른 필드들
}

 

@Repository
public class ChatRoomRepository {

    @PersistenceContext
    private EntityManager entityManager;

    public List<ChatRoomUserDTO> findChatRoomsWithUsers() {
        return entityManager.createNativeQuery(
                "SELECT cr.id AS chatRoomId, cr.name AS chatRoomName, u.name AS userName " +
                "FROM chat_rooms cr JOIN users u ON cr.user_id = u.id",
                "ChatRoomUserMapping"
        ).getResultList();
    }
}

 

 

매우 복잡한 네이티브 쿼리가 존재할 때 사용할만 하다. JPQL로 작성하기 어려운 복잡한 SQL을 다뤄야 할 때 사용된다.(e.g. 서브쿼리, 복잡한 조합이나 통계 쿼리) 또한 성능 최적화가 필요한 경우에 사용 가능하다. 데이터베이스 I/O를 최소화하거나, 네이티브 SQL에서 JPA의 제한을 벗어나야 할 때 사용된다.

 

출처: https://hyj.oopy.io/query-tuning

 

결론

DTO를 사용하여 특정 컬럼만 조회하고, 대용량 데이터를 제외하는 방식은 효과적인 쿼리 튜닝 기법이다. 이는 데이터베이스 I/O와 네트워크 전송량을 줄여 성능을 최적화하는 데 중요한 역할을 한다.

실무에서도 리스트형 화면이나 읽기 전용 API에서 널리 사용되는 최적화 기법 중 하나이다. 필요 없는 데이터를 제외함으로써 데이터베이스와 애플리케이션 간의 자원 사용을 줄이고 성능을 개선할 수 있다.