[번역] Batch Fetching - 객체 그래프 로딩을 최적화 하기 (JPA/ECLIPSELINK) - 3(마지막) 기술

자, 여태까지 설명한 내용이 무엇을 의미할까? 흠, 모든 환경과 유스케이스는 서로 다르며, 그렇기 때문에 모든 경우에 적합한 완전한 해결책은 없다는 것이다. 서로 다른 쿼리 최적화는 서로 다른 상황에 적합하다. 다음에 설명한 벤치마크 결과는 앞서 설명한 방식들의  잠재적인 성능 향상을 보여줄 것이다. 

 

다음 벤치마크 결과는 로컬 네트워크 상의 저렴한 하드웨어에서 오라클을 java se 환경에서 단일 쓰래드로 구동시켜 나온 결과이다. 각 테스트는 60초간 실행 되었고, 실행된 횟수를 기록했다. 각 테스트는 5번 반복 했다. 최소/최대 값은 제외 했다. 숫자 자체는 별 의미가 없으며 각 방식에 대한 % 차이를 살펴 보기 바란다. 

 

벤치마크에서는 최적화되지 않은 쿼리, join fetching, batch fetching을 적용했다. 

 

Simple run (fetch address, phoneNumbers)

Query

Average (queries/minute)

%STD

%DIF (of standard)

standard

5897

0.5%

0

join fetch

14024

1.1%

+137%

batch fetch (JOIN)

11190

4.5%

+89%

batch fetch (EXISTS)

13764

0.4%

+133%

batch fetch (IN)

14341

0.6%

+143%

 

 

첫번쨰 결과만 보면 join fetch가 상당히 좋아 보인다.  첫번째 테스트에서는 2개의 관계만 읽어 왔다. 더 많은 관계를 읽어 오면 어떻게 될까?

 

 

 

Complex run (fetch address, phoneNumbers, projects, manager, managedEmployees, emailAddresses, responsibilities, jobTitle, degrees)

Query

Average (queries/minute)

%STD

%DIF (of standard)

standard

1438

0.7%

0%

join fetch

1121

0.4%

-22%

batch fetch (JOIN)

3395

3.8%

+136%

batch fetch (EXISTS)

3768

2.6%

+162%

batch fetch (IN)

3893

0.5%

+170%

 

 

두번째 테스트를 보면 join fetch의 문제점이 들어 난다. join fetch는 실제로는  최적화 되지 않는 쿼리보다 느려진다. (-22%). 이건 본질적으로 여러 테이블을 조인하면 더 많은 데이터를 가져와서 처리해야 하기 때문이다.  반면에  batch fetch는 여전히 우월한 성능을 보여준다.