QueryDSL을 이용해 다중 해시태그 조회하기

해피하우스 때와 동일하게 태그 서비스를 제공하여 파티룸 테마를 구분하고 목적에 따른 조회를 쉽게 만들고 싶었다.

Spring + JPA 환경에서 태그 서비스를 제공하기 위해 고려해야 할 부분이 2가지가 있는데 바로 다대다 관계를 지키는 것, 그리고 이를 jpa에 맞게 매핑하는 것이라고 말하고 싶다.

간단해 보여도 막상 구현하다보면 복잡하니 이번에 잘 정리해두고 다음에 다시 찾아보고자 한다!

테이블 구성하기

연결 테이블(Join Table)

찬찬히 생각해보자.

파티룸을 설명하기 위한 수단으로 해시태그를 설정하기 위해서는 하나의 파티룸에 여러개의 해시태그를 걸어 각각의 해시태그가 가진 의미를 조합해 파티룸을 소개하는 것이 좋다. 즉, 하나의 파티룸에 여러개의 해시태그를 달고싶다는 말이다.

반대로 하나의 해시태그를 놓고 보면 어떨까? #불금 이라는 해시태그가 꼭 하나의 파티룸에서만 사용되어야할까? 만약 그렇다면 #불금 해시태그를 사용하기 위해 사람들은 월요일부터 미리 파티룸을 만들어놓아야 할지도 모른다. 해시태그 입장에서 보면 하나의 해시태그는 여러개의 파티룸에 설정될 수 있을 것이다.

따라서 파티룸과 해시태그는 다대다(n:m) 관계를 가진다. 다대다 관계는 해소되어야한다. 테이블 내에서 데이터의 중복이 발생하고 테이블이 복잡해지며 조회가 어려워지기때문이다. 이 관계를 해소하기 위해서는 파티룸과 해시태그 데이터를 각각 하나씩 연결해주는 역할이 필요하고, 이 역할을 하는 것이 연결 테이블(조인 테이블)이다. 고작 두 테이블을 연결해주는 용도로 테이블을 새롭게 만드는 것이 어색하게 들릴지 몰라도 이 테이블의 역할은 어마어마하다.

연결 테이블 덕분에 파티룸과 해시태그 내부에는 복잡한 둘의 관계는 빼내고 각각 자신의 고유한 정보만을 보유할 수 있다. room_tag 테이블에는 파티룸 id와 해시태그 id를 하나씩 연결하여 하나의 방에 설정됐던 해시태그를 모두 저장하고, 반대로 하나의 해시태그도 여러 파티룸에 설정되었던 관계를 표현하여 저장할 수 있다.

쿼리문 작성

안타깝게도 문제의 시작은 여기서부터다.

서비스를 이용하는 사용자는 #불금이라는 해시태그와 #야근이라는 해시태그를 조합하여 비록 금요일에 야근 중이지만 자신과 같은 처지의 사람들과 내적 흥 발산 파티를 즐기고 싶을 수 있다. 만약 #불금 또는 #야근 이라는 해시태그를 설정한 파티룸을 모두 반환한다면 어떤 파티룸은 들어갈 수도 없을 정도로 시끄러울 것이고, 어떤 파티룸은 파티룸을 가장한 사내 회의를 진행하고 있을 수도 있다. #불금 파티룸만 반환해서도 안 되고 #야근 파티룸만 반환해서도 안 된다. #불금과 #야근이라는 태그를 동시에 설정한 파티룸만 반환해야 한다. 여기에 추가적으로 다른 태그가 붙어있는 것은 상관이 없다.

roomtag 연결 테이블에서 파티룸을 조회하고 싶지만 #불금과 #야근이라는 태그를 모두 설정한 파티룸이어야 한다. 합집합이 아니라 교집합이어야 하는 것이다. roomtag 테이블의 각 행은 하나의 방과 하나의 해시태그만을 연결하고 있기때문에 단순히 AND 연산을 취한다고 해결될 일이 아니다. 각 행은 #불금과 #야근이라는 해시태그를 동시에 의미할 수 없다(애초에 다대다 관계를 해소하기 위한 목적이었으므로 당연하다).

그렇다면 다음으로 생각하는 방법은 #불금 태그를 포함하는 방 데이터를 모두 가져오고 #야근 태그를 포함하는 방 데이터를 모두 가져와 JOIN하는 방법이다. 하지만 이 방법도 불가능하다. 사용자가 조합하고 싶은 태그가 2개뿐이라는 보장이 없으며 태그가 늘어날수록 JOIN 연산도 동적으로 늘어나야한다. 😣…

결국 채택할 수 있는 쿼리문은 다음과 같은 형태가 된다.

SELECT room_id
FROM room_tag
WHERE tag_id in (1, 2, 3)
GROUP BY room_id
HAVING count(room_id) = 3;

WHERE 문의 in 연산을 통해 원하는 해시태그와 관련된 room_tag 정보를 모두 가져온다. 쿼리문 3번째 라인인 WHERE 문 까지만 실행하면 A방에서 1, 2, 3을 모두 설정한 경우 (A, 1), (A, 2), (A, 3)의 형태로 방 번호가 중복적으로 조회될 것이다. B방에서 1, 2를 설정한 경우 (B, 1), (B, 2)의 데이터가 추가되어 조회될 것이다.

실행 결과를 보다보면 한가지 생각이 떠오른다. 방 번호로 묶어버리고 싶다! (A, 1 2 3), (B, 1 2) 이렇게 말이다. 이를 위한 쿼리가 쿼리문 4번째 라인인 GROUP BY 이다.

여기서 멈춘다면 B방은 1, 2 번 태그만 설정했는데도 조회 결과에 추가될 것이다. 따라서 오로지 3가지 태그만을 설정한 방을 추출하기 위해 HAVING 조건을 추가한다. GROUP BY로 그룹화한 결과에 조건을 추가하는 용도이다. 각 방으로 그룹화한 상태로 각 방의 태그 개수를 구한다면 각 방은 태그 1, 2, 3 중 몇 가지의 태그를 설정했는지 알 수 있다.

조금 복잡하지만 join이나 서브쿼리 연산 없이 데이터를 조회할 수 있었다.

JPA QueryDSL 구현하기

QueryDsl 방식으로 조회하기

위의 쿼리문은 아주 단순한 형태는 아니다. 아주 단순한 조회 쿼리는 Query Method 방식을 이용해 메서드 명으로 자동으로 쿼리를 만들면 쉽지만, 위의 쿼리는 in 체크도 해야하고 그룹화도 해야하며 그룹화 결과에 조건까지 추가적으로 달아줘야 한다. 따라서 JPA를 활용한 방법 중 QueryDsl을 이용하여 각 연산을 메서드로 체이닝하여 구현하면 좋을 것 같다.

JPA는 단순 쿼리 mapper가 아니다. 좀 더 객체지향적으로 접근하여 서비스 프로그램의 객체와 DB 데이터를 연결해주는 ORM 이다. 그러므로 우리는 테이블의 pk 컬럼이나 id를 기준으로 sql문을 생각하지 않고, 엔티티 클래스를 기반으로 메서드를 생각해야 한다.

코드 먼저 확인해보자.

// 시행착오 코드
public Page<Room> getRoomByTag(List<Tag> hashtags, Pageable sort) {
    JPQLQuery<Room> query = jpaQueryFactory.select(qRoomTag.room).from(qRoomTag)
            .where(qRoomTag.tag.in(hashtags))
            .groupBy(qRoom)
            .having(qRoomTag.tag.count().eq((long) hashtags.size()));

    List<Room> roomList = getQuerydsl().applyPagination(sort, query).fetch();
    return new PageImpl<>(roomList, sort, query.fetchCount());
}

// 완성 코드
public Page<Room> getRoomTagByTagName(String[] hashtags, Pageable sort) {
    List<Room> roomList = jpaQueryFactory.select(qRoomTag.room).from(qRoomTag)
            .where(qRoomTag.tag.tagName.in(hashtags))
            .groupBy(qRoomTag.room)
            .having(qRoomTag.tag.count().eq((long) hashtags.length)).fetch();

    return new PageImpl<>(roomList, sort, query.fetchCount());
}

체이닝하여 사용한 메서드만 보면 쿼리문과 동일하다. 하지만 내가 실수한 부분을 보면 sql 역할을 하는 메서드가 문제가 아니라 데이터를 객체지향적으로 생각하지 않았기때문에 발생한 실수라는걸 알 수 있다.

먼저 가장 바깥 스코프의 2가지 메서드를 보자. 두 메서드는 매개변수를 다른 형태로 받는다. 프론트에서 요청으로 들어온 해시태그의 형태에 대한 설명을 덧붙이면 해시태그는 문자열 형태로 배열에 저장되어있다(String[] hashtags). 이것으로 미루어 생각해보면 완성 코드에서는 요청의 형식을 그대로 사용했고, 시행착오 코드에서는 이 함수를 부르기 전에 요청을 바탕으로 Tag 객체 리스트를 만들어 사용했을 것을 알 수 있다. 실제로 시행착오 코드 이전에는 요청으로 받은 (String[] hashtags)형태 태그를 tag 테이블에서 조회하여 tag 객체 리스트를 만들어왔다.

뭔가 이상하지 않은가? 이미 태그명을 알고있는데 태그 번호를 모른다고 또 다시 태그를 조회해야한다니… 객체지향 프로그래밍에서 엔티티를 구성했다면 이미 Tag 객체 내부에는 태그 번호와 태그명이 필드로 표현되어있다. 마찬가지로 roomTag 객체 내부에도 태그명은 아니지만 태그명을 포함한 tag 객체가 저장되어 있으므로 필드에 접근하여 사용하면 된다. qRoomTag.tag.tagName.in(hashtags) 처럼 말이다.

다음으로 group by() 메서드를 보자. 시행착오 코드에서는 단순히 room 객체를 그룹화 조건으로 설정했지만 완성 코드에서는 roomTag 객체 내부에 필드로 존재하는 room 객체를 그룹 조건으로 설정한다. JPA의 QueryDsl은 프로그램 객체와 DB를 연결해주고 있기때문에 아무리 같은 room 타입이라고 할지라도 roomTag 객체의 필드에 존재하는 room 객체를 명시해야 DB와 엔티티를 연결해줄 수 있다.

하… 아무것도 모르고 단순하게 room 객체를 지정했다가 jpa로부터 자꾸만 잘못된 컬럼, 없는 컬럼, 이해할 수 없는 컬럼이라는 에러를 받아야 했다. 분명 sql문과 동일한데 왜 안될까 했는데 에러를 잡을 때도 sql문법 오류가 아닌 이상 sql문을 기준으로 생각할 것이 아니라 객체지향 기반으로 생각했어야 했다.

jpa가 쉽진 않지만 정말 유용하다는 것을 다시한번 깨달았다. 왜냐면 6시 전까지 기능 구현은 끝내야겠는데 DB 조회는 자꾸만 실패하길래 쿼리문 자체를 자바 애플리케이션 단에서 프로그래밍하여 구현했었다. 아래가 그 코드고 별로 설명하고 싶지 않다… 🙄

String[] hashtags = word.substring(1).split("#");
HashMap<Room, Integer> roomTagMap = new HashMap<>();

// tag 테이블에서 hashtags에 해당하는 태그 리스트를 모두 가져옴
List<Tag> tagList = tagRepository.findByTagNameIn(hashtags);

for (Tag tag : tagList) {
    // roomTag 테이블에서 각 hashtag에 해당하는 룸 리스트 모두 가져옴
    List<RoomTag> searchedRooms = roomTagRepository.findByTag(tag);

    // 맵에 룸과 찾는 해시태그를 몇개 포함하는지 저장
    for (RoomTag searchedRoom : searchedRooms) {
        Room curRoom = searchedRoom.getRoom();
        roomTagMap.computeIfPresent(curRoom, (k, v) -> v+1);
        roomTagMap.putIfAbsent(curRoom, 1);
    }
}

// 조회하는 해시태그 개수만큼 해시태그를 포함한 룸만 반환
List<Room> roomContainingHashtags = new ArrayList<>();
int size = hashtags.length;
for (Map.Entry<Room, Integer> entry : roomTagMap.entrySet()) {
    if (entry.getValue() == size) roomContainingHashtags.add(entry.getKey());
}

roomList = new PageImpl<>(roomContainingHashtags, sort, roomContainingHashtags.size());