•
지연로딩, 즉시로딩 차이 구분 (엔티티 코드에 적용)
◦
즉시로딩, 지연로딩 관련 블로그 게시글
▪
◦
지연로딩
▪
지연로딩이란, 필요한 시점에 연관된 객체의 데이터를 불러오는 것이다.
@ManyToOne(fetch = FetchType.LAZY) //Team을 조회할 때 지연로딩을 사용하곘다!
@JoinColumn(name = "team_id")
Team team;
Java
복사
◦
즉시로딩
▪
즉시로딩이란 데이터를 조회할 때, 연관된 모든 객체의 데이터까지 한 번에 불러오는 것이다.
@ManyToOne(fetch = FetchType.EAGER) //Team을 조회할 때 즉시로딩을 사용하곘다!
@JoinColumn(name = "team_id")
Team team;
Java
복사
지연 로딩을 사용하면 Member를 조회하는 시점이 아닌 실제 Team을 사용하는 시점에 쿼리가 나가도록 할 수 있다는 장점이 있다.
위 예제의 즉시 로딩에서는 member와 연관된 Team이 1개여서 Team을 조회하는 쿼리가 나갔지만, 만약 Member를 조회하는 JPQL을 날렸는데 연관된 Team이 1000개라면?
Member를 조회하는 쿼리를 하나 날렸을 뿐인데 Team을 조회하는 SQL 쿼리 1000개가 추가로 나가게 된다.
그렇기 때문에 가급적이면 지연로딩을 사용하는 것이 좋다.
(성능면에서 차이가 남)
즉시로딩(Immediate Loading)을 선택하는 이유
1.
객체 간의 관계를 활용하기 편리: 즉시로딩을 사용하면 객체를 조회할 때 연관된 모든 객체가 한 번에 로딩되므로 객체 간의 관계를 편리하게 활용할 수 있습니다.
모든 연관된 데이터가 이미 로딩되어 있으므로 어떤 객체를 사용할 때 별다른 데이터베이스 조회 없이 객체 그래프를 따라 이동할 수 있습니다.
2.
복잡한 조회를 단순화: 데이터베이스에서 조인을 사용하여 복잡한 연관관계를 해결할 필요 없이, 즉시 로딩으로 모든 데이터를 한 번에 가져올 수 있습니다.
지연로딩(Lazy Loading)을 선택하는 이유 (실무에서는 지연로딩을 권장함!)
1.
성능 최적화: 즉시로딩은 모든 연관된 데이터를 한 번에 가져오기 때문에, 필요하지 않은 데이터까지 불필요하게 로딩될 수 있습니다. 이는 성능 저하를 야기할 수 있습니다.
지연로딩은 필요한 시점에만 데이터를 로딩하기 때문에 성능을 최적화할 수 있습니다.
2.
데이터 접근을 최적화: 사용자가 실제로 해당 데이터를 사용할 때만 로딩하므로 데이터베이스 접근이 최적화됩니다. 따라서 시스템 전체적으로 데이터 로딩에 대한 부하가 분산될 수 있습니다.
3.
순환 참조 방지: 지연로딩을 사용하면 객체 간의 연관관계에서 순환 참조가 발생할 확률이 줄어듭니다. 객체를 조회할 때 실제로 필요한 데이터만 로딩되므로 무한한 순환 참조를 방지할 수 있습니다.
4.
메모리 사용 최적화: 즉시로딩은 연관된 모든 데이터를 로딩하기 때문에 메모리를 많이 사용할 수 있습니다. 지연로딩은 필요한 데이터만 로딩하기 때문에 메모리 사용을 최적화할 수 있습니다.
⇒ @ManyToOne, @OneToOne은 DEFAULT가 FetchType.EAGER. @ManyToMany, @OneToMany는 DEFAULT가 FetchType.LAZY
// 참고 : https://velog.io/@k_ms1998/JPA-%EC%A7%80%EC%97%B0-%EB%A1%9C%EB%94%A9fetchFetchType.LAZY
실무에서는 지연 로딩 방식을 사용하는 것이 매우 권장됩니다.
즉시 로딩시, 연관된 테이블들을 JOIN으로 모두 가져오기 때문에, 예상하치 못한 SQL문이 처리되며, JPQL에서는 의도한 쿼리 + 연관된 테이블의 갯수 N개 만큼, 총 N+1개의 쿼리가 처리 됩니다.
Plain Text
복사