referencedColumnName 을 사용한 Join 과 N+1 문제
JPA 를 사용할때 N+1 로 인한 성능 저하는 경계해야할 대표적인 문제중에 하나입니다.
N+1 이 발생하는 경우는 여러가지가 있지만 그 중에서 referncedColmnName 과 관련된 내용을 코드 분석과 함께 알아보고자 합니다.
N+1 재현 환경
Repo : https://github.com/SonUngBea/hibernate-project/tree/N%2B1/referencedName
ERD
DATA
| Student | School |
 |
 |
Code
Student Entity
- NOTE : @ManyToOne 으로 Join 을 걸때 school 의 PK 인 id 가 아닌 name 으로 Join 을 걸었다.
@Entity
public class Student implements Serializable {
@Id
private Long id;
private String name;
private Long schoolId;
private String schoolName;
@ManyToOne
@JoinColumn(name = "schoolName", referencedColumnName = "name", insertable = false ,updatable = false)
private School school;
}School Entity
@Entity
public class School implements Serializable {
@Id
private Long id;
private String name;
}Load all student
List<Student> students = em.createQuery("select m from Student as m", Student.class).getResultList();Result
불러온 Student 들의 School 을 채우기 위해서 Student 갯수만큼 School 을 조회하기 위한 Query 가 날라간 것을 확인할 수 있다.
Hibernate:
/* select
m
from
Student as m */ select
student0_.id as id1_1_,
student0_.name as name2_1_,
student0_.schoolName as schoolNa4_1_,
student0_.schoolId as schoolId3_1_
from
Student student0_
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?
N+1 해결해보기
일반적으로 @ManyToOne N+1 문제를 해결하기 위하여 FetchType 을 LAZY 로 설정하여 School 을 참조할때 불러오도록한다.
@Entity
public class Student implements Serializable {
@Id
private Long id;
private String name;
private Long schoolId;
private String schoolName;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "schoolName", referencedColumnName = "name", insertable = false ,updatable = false)
private School school;
}위와 같이 ManyToOne 의 fetchType 을 LAZY 로 설정하여 실행해보았다.
Hibernate:
/* select
m
from
Student as m */ select
student0_.id as id1_1_,
student0_.name as name2_1_,
student0_.schoolName as schoolNa4_1_,
student0_.schoolId as schoolId3_1_
from
Student student0_
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?하지만 여전히 Student 갯수만큼 School 을 조회하는 쿼리가 날라가는 것을 확인할 수 있다.
fetchType 이 LAZY 임에도 불구하고 Student 의 멤버 변수인 school 에 접근하지 않았음에도 fetch 하는 이유가 무엇일까
LAZY 동작하지 않는 원인 파악
Hibernate 를 이용하여 Entity 를 조회하게되면 우리가 작성한 Entity 를 Parsing 하여 resolve 하는 단계를 거치게 된다. 이때 Parsing 된 Type 별로 각기 다른 resolve() 함수를 타게 되며 @ManyToOne 을 사용하여 Join 을 걸어 놓은 멤버변수는 EntityType 이 된다.
따라서 EntityType 클래스의 resolve() 함수에서 해당 멤버변수를 초기화 하게 된다.
public Object resolve(Object value, SessionImplementor session, Object owner) throws HibernateException {
if ( isNotEmbedded( session ) ) {
return value;
}
if ( value != null && !isNull( owner, session ) ) {
if ( isReferenceToPrimaryKey() ) {
return resolveIdentifier( (Serializable) value, session );
}
else if ( uniqueKeyPropertyName != null ) {
return loadByUniqueKey( getAssociatedEntityName(), uniqueKeyPropertyName, value, session );
}
}
return null;
}해당 함수에 isRefernceToPrimaryKey() 에 따라서 resolveIdentifier() 를 호출할지 loadByUniqueKey() 를 호출할지 결정하는 조건문을 확인할 수 있다.
Student 엔티티에서 볼 수 있듯이 refernceColumnName 을 사용하여 School 테이블의 PK 가 아닌 Column 를 참조하도록 설정하였다.
그로 인해 isRefernceToPrimaryKey() 는 false 가 리턴되어 loadbyUniqueKey() 함수를 사용하여 School Entity 를 채우게 된다.
public Object loadByUniqueKey(
String entityName,
String uniqueKeyPropertyName,
Object key,
SessionImplementor session) throws HibernateException {
final SessionFactoryImplementor factory = session.getFactory();
UniqueKeyLoadable persister = ( UniqueKeyLoadable ) factory.getEntityPersister( entityName );
//TODO: implement caching?! proxies?!
EntityUniqueKey euk = new EntityUniqueKey(
entityName,
uniqueKeyPropertyName,
key,
getIdentifierOrUniqueKeyType( factory ),
persister.getEntityMode(),
session.getFactory()
);
final PersistenceContext persistenceContext = session.getPersistenceContext();
Object result = persistenceContext.getEntity( euk );
if ( result == null ) {
result = persister.loadByUniqueKey( uniqueKeyPropertyName, key, session );
}
return result == null ? null : persistenceContext.proxyFor( result );
}loadbyUniqueKey() 에서는 EntityUniqueKey 클래스를 사용하여 영속성컨텍스트에서 해당 엔티티를 조회해보고 리턴값이 없다면 DB 조회를 하게 된다.
즉, loadbyUniqueKey() 함수 내에는 LAZY 처리를 위한 기능이 없기 때문에 LAZY 옵션을 주더라도 EAGER 로 동작하게 되는 것이다.
그렇다면 resolveIdentifier() 는 어떨까?
protected final Object resolveIdentifier(Serializable id, SessionImplementor session) throws HibernateException {
boolean isProxyUnwrapEnabled = unwrapProxy &&
getAssociatedEntityPersister( session.getFactory() )
.isInstrumented();
Object proxyOrEntity = session.internalLoad(
getAssociatedEntityName(),
id,
eager,
isNullable() && !isProxyUnwrapEnabled
);
if ( proxyOrEntity instanceof HibernateProxy ) {
( ( HibernateProxy ) proxyOrEntity ).getHibernateLazyInitializer()
.setUnwrap( isProxyUnwrapEnabled );
}
return proxyOrEntity;
}resolveIdentifier() 내에는 internalLoad() 함수를 호출할때 eager 라는 파라미터를 받고 있으며 Lazy 로 동작해야할 경우 Proxy 가 리턴될 것을 암시하는 변수명을 확인할 수 있다.
resolveIdentifier() 를 호출할 경우에 LAZY 로딩이 동작하는 것을 확인해보기 위하여 Student Entity 의 School 조인을 schoolName 이 아닌 schoolId 로 수정하여 실행해보았다.
@Entity
public class Student implements Serializable {
@Id
private Long id;
private String name;
private Long schoolId;
private String schoolName;
@ManyToOne(fetch = FetchType.LAZY)
@JoinColumn(name = "schoolId", insertable = false ,updatable = false)
private School school;
}예상한대로 resolveIdentifier() 함수를 타게 되었고 아래와 같이 LAZY 로딩이 정상적으로 동작하였다.
Hibernate:
/* select
m
from
Student as m */ select
student0_.id as id1_1_,
student0_.name as name2_1_,
student0_.schoolId as schoolId3_1_,
student0_.schoolName as schoolNa4_1_
from
Student student0_
PK 가 아닌 컬럼으로 조인한 경우에 Lazy fetch 가 동작하지 않는 이유
PK 가 아닌 컬럼으로 조인하였을때 LAZY fetch 가 동작하지 않는 이유가 궁금하여 찾아보았다.
Lazy Initialize 기능을 사용하려면 Hibernate Proxy 로 감싸진 객체를 Return 해야하는데 Proxy 는 Null 을 감쌀 수 없기 때문에 PK 가 아닌 컬럼으로 Join 이 걸려있으면 Null 이 아닐 가능성이 있으므로 LAZY 로 동작하지 않도록 하였다는 내용을 찾을 수 있다.
하지만 이와 관련된 코드를 찾지는 못하였다.
결론
N+1 문제를 해결하기 위하여 Lazy Fetch 를 적용한다고 하더라도 일부 케이스에서는 해결책이 될 수 없다.
추가정보1) Hiberate4 에서는 Student 의 School 이 동일하더라도 매번 School 을 찾기 위해 쿼리가 날라간 반면 Hibernate5 에서는 School 이 동일하다면 한번의 쿼리만 날라갔다.
Hibernate4
같은 School 이더라도 매번 조회 함
Hibernate:
/* select
m
from
Student as m */ select
student0_.id as id1_1_,
student0_.name as name2_1_,
student0_.schoolName as schoolNa4_1_,
student0_.schoolId as schoolId3_1_
from
Student student0_
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?Hibernate5
같은 School 은 한번 조회하고 다시 쿼리가 안날라감
Hibernate:
/* select
m
from
Student as m */ select
student0_.id as id1_1_,
student0_.name as name2_1_,
student0_.schoolName as schoolNa4_1_,
student0_.schoolId as schoolId3_1_
from
Student student0_
Hibernate:
/* load School */ select
school0_.id as id1_0_0_,
school0_.name as name2_0_0_
from
School school0_
where
school0_.name=?
이 차이는 앞서 살펴보았던 loadbyUniqueKey() 내부에서 영속성 Context 에 School 이 저장되느냐 안되느냐의 차이에서 발생한다.
final PersistenceContext persistenceContext = session.getPersistenceContext();
Object result = persistenceContext.getEntity( euk );
Hibernate4 의 경우에는 persistenceContext.getEntity( euk ); 했을때 이전에 조회한 Entity 가 Return 되지 않아 DB 에서 다시 조회하였고 Hiberante5 의 경우에는 이전에 조회한 Entity 가 Return 되어 영속성 컨텍스트에 저장되어있는 Entity 가 사용되어 쿼리가 다시 날라가지 않았다.
// If the entity was not in the Persistence Context, but was found now,
// add it to the Persistence Context
if (result != null) {
persistenceContext.addEntity(euk, result);
}
Hibernate5 부터 loadbyUniqueKey() 내부에서 불러온 Entity 를 영속성 컨텍스트에 저장하고 있기 때문에 발생하는 차이이다.
즉, 불러온 Student 의 School 이 모두 같을 경우 Hibernate4 의 경우에는 Student 갯수 만큼 School 조회 쿼리가 날라가고 Hibernate5 의 경우에는 School 조회 쿼리가 딱 한번만 날라간다. 하지만 School 의 종류가 다르다면 Hibernate5 에서도 School 의 종류 만큼 쿼리가 날라간다.