저번글에 프록시(proxy)와 지연로딩의 개념에 대해서 간단히 알아보았다. 이번에는 지연 로딩에 관해서 조금은 심도깊게 알아보자.
지연 로딩이란?
회원과 팀이 있다고 가정해보자. 회원과 팀을 지연 로딩으로 설정하였다. 따라서 회원을 호출한다면 회원만 조회하고 팀은 조회하지 못한다. 그 대신 회원의 team 변수에 프록시 객체를 넣어둔다.
Team team = member.getTeam();반환된 팀 객체는 프록시 객체이다. 이 프록시 객체는 실제 사용될 때 까지 데이터 로딩을 미루는데, 이것을 지연 로딩(LAZY LOADING)이라고 한다.
이처럼 실제 데이터가 필요한 순간이 되어서야 데이터베이스를 조회해서 프록시 객체를 초기화한다.
FetchType.LAZY
지연 로딩(LAZY LOADING)을 사용하려면 @ManyToOne의 fetch 속성을 FetchType.LAZY로 설정해야한다.
@ManyToOne(FetchType.LAZY)@XToMany는 default 값이 LAZY이기 때문에 따로 설정할 필요가 없다.
@OneToMany(default)즉시 로딩 vs 지연 로딩
처음부터 연관된 엔티티를 모두 영속성 컨텍스트에 올려두는 즉시 로딩과 필요할 때마다 SQL을 실행해서 연관된 엔티티를 가져오는 지연 로딩 중 무엇이 좋을까 ?
결론부터 말하면 상황에 따라 다르다 조금은 애매한 대답이지만 맞는 말이다. 좀 더 쉬운 이해를 돕기 위해 예를 들어보자.
ex) 대부분의 애플리케이션 로직에서 회원과 팀 엔티티를 같이 사용한다.
위와 같은 상황은 SQL 조인을 사용해서 회원과 팀 엔티티를 한번에 조회하는 것이 성능면에서 더 우위를 차지할 수 있다.
하지만 반대로
ex) 대부분의 애플리케이션 로직에서 회원과 팀 엔티티를 따로 사용한다.
이렇게 되면 당연히 지연 로딩을 사용하는 것이 맞는 판단이다.
즉시 로딩, 지연 로딩 정리
-
즉시 로딩(EAGER) : 연관된 엔티티를 즉시 조회한다.(프록시 객체를 만들지 않고 실제 객체를 바로 사용함)
-
지연 로딩(LAZY) : 연관된 엔티티를 프록시로 조회한다.
