안녕하세요 FetchGroups에서 Multiset방식 사용하면 어떤가 해서 물어봅니다

안녕하세요 공부하다가 보니

FetchGroups방식으로 했을때 Map으로 반환되고 DTO로 변환해야하는 오버헤드가 발생하는데요

Multiset방식으로 하면 1:N 관계에서 바로 DTO로 반환 할 수 있는데요

코드 보기가 조금은 더 복잡해 보이지만 WHERE절이 있을때 현재 테이블 데이터와 인덱스 상으로는 성능적으로 더 괜찮은거 같아서 multiset방식은 강의에 없어서 어떤지 궁금해서 여쭤봅니다

public List<ActorFilmography> findActorFilmographyWithMultiset(ActorFilmographySearchOption searchOption) {
    final JFilmActor FILM_ACTOR = JFilmActor.FILM_ACTOR;
    final JFilm FILM = JFilm.FILM;

    return dslContext.select(
                    ACTOR,
                    DSL.multiset(
                            DSL.select(FILM.fields())
                                    .from(FILM)
                                    .join(FILM_ACTOR)
                                    .on(FILM.FILM_ID.eq(FILM_ACTOR.FILM_ID))
                                    .where(
                                            FILM_ACTOR.ACTOR_ID.eq(ACTOR.ACTOR_ID),
                                            containsIfNotBlank(FILM.TITLE, searchOption.getFilmTitle())
                                    )
                    ).convertFrom(r -> r.into(Film.class))
            )
            .from(ACTOR)
            .where(
                    containsIfNotBlank(ACTOR.FIRST_NAME.concat(" ").concat(ACTOR.LAST_NAME), searchOption.getActorName())
            )
            .fetch(record -> new ActorFilmography(
                    record.value1().into(Actor.class),
                    record.value2()
            ));
}

WHERE 조건 포함 시 성능 비교

fetchGroups 방식 (cost=405, rows=609)

Film 필터링 먼저 → FilmActor 조인 → Actor 필터링

1. film 테이블 스캔 (1000 rows)

└─ LIKE '%COMMANDMENTS EXPRESS%' → 111 rows

2. film_actor 인덱스 조회 (idx_fk_film_id) → 609 rows

3. actor PRIMARY KEY 조회 → 609 rows

└─ LIKE '%LOLLOBRIGIDA%' → 1 row (최종)

특징:

- Film 조건이 선택적이면 먼저 필터링하여 조인 범위 축소

- 하지만 Actor 필터링은 마지막에 수행 (비효율)

- 609개 row가 네트워크 전송 → 애플리케이션에서 1개로 그룹핑

---

multiset 방식 (cost=20.2 + 13.3 × filtered_actors)

Actor 필터링 먼저 → 각 Actor의 Film 서브쿼리

1. actor 테이블 스캔 (200 rows)

└─ LIKE '%LOLLOBRIGIDA%' → 1 row (필터링 후)

2. 필터링된 1개 actor에 대해 서브쿼리 실행:

- film_actor PRIMARY KEY 조회 (27.3 rows 추정)

- film PRIMARY KEY 조회 (27.3번)

- LIKE '%COMMANDMENTS EXPRESS%' → 1개 매칭

특징:

- Actor 조건을 먼저 적용하여 서브쿼리 실행 횟수 최소화

- 필터링된 1개 Actor만 네트워크 전송 (JSON 포함)

- Film 필터링은 각 actor 서브쿼리 내부에서 수행

---

실제 Total Cost 계산

fetchGroups

Total: 405

네트워크 전송: 609 rows (Actor + Film 중복 포함)

애플리케이션 처리: Map 생성 + Stream 변환

multiset

Total: 20.2 + (13.3 × 1) = 33.5

네트워크 전송: 1 row (Actor + JSON array)

애플리케이션 처리: JSON 역직렬화

결론: WHERE 조건이 있으면 multiset이 압도적으로 유리 (405 vs 33.5)

FetchGroups는 Actor를 나중에 필터링하고 multiset은 actor를 먼저 필터링해서 1개에 대한 film을 여러개 가져와서 현재 데이터에서는 더 유리한데 일반적인 사용법이 궁금합니다