Hibernate Performance Tips
  Dashboard > 프레임워크 > ... > Hibernate > Hibernate Performance Tips
Community
  프레임워크 Log In | Sign Up   View a printable version of the current page.  
Added by 박재성, last edited by 박재성 on 9월 05, 2005
Labels: 
(None)

Hibernate Tips

Hibernate Framework을 사용할 경우 기존의 DAO내에서 SQL을 직접 작성할 때보다 실행 속도가 떨어지는 것이 사실이다. 따라서 Hibernate를 사용할 경우 실행속도의 향상을 위한 좋은 팁들이 있을 것으로 생각한다. 이 문서는 그러한 팁들을 정리하여 Hibernate를 사용하는 개발자들이 실행속도 때문에 고생하는 일이 없도록 하기 위함이다.

온라인 상에서 볼 수 있는 유용한 Performance Tips나 프로젝트를 진행하면서 실행속도의 향상을 위한 좋은 해결책이 있다면 공유해 주시기 바랍니다. 외국문서의 경우 번역이 힘드시다면 단지 이 문서에 첨부해 주시기 바랍니다. 그러한 작은 노력도 Hibernate를 사용하는 국내의 많은 개발자들에게 큰 힘이 될 것이라 생각합니다.

번역 : 자바지기, 윤상필

1. 가장 최신버전을 사용해라. Hibernate 3이 현재 베타 버전이지만 새롭게 지원하는 상당히 유용한 많은 기능들 때문에 실행속도의 향상을 가져올 수 있으므로 Hibernate 3의 최신 버전을 이용해 개발해라.

2. 각 모델간의 모든 관계를 Lazy Loading으로 구현해라.(Hibernate 3은 Lazy Loading이 디폴트이다) 그리고 eagerly 조인 혹은 데이터 fetch 는 특정한 유스 케이스에서만 의식적인 선택사항으로 해야 한다.

3. 당신의 세션관리 전략을 빨리 결정해야 한다. 하나의 request 당 한 세션을 둘 것인가, 분리된 객체를 가진 request 당 세션을 둘 것인가, 다수의 request을 교차하는 "어플리케이션 트랜잭션" 당 세션을 둘 것인가 등을 말이다. 이것이 클라이언트-서버 어플리케이션에서 어떻게 동작할 것인지에 대해서는 확신하지 마라. 이것은 상당부분 웹 어플리케이션 관점으로부터 나온 것이다.

4. flush 전략을 빨리 수립하라 : 하이버네이트 auto-flush에 맡겨두던가, 데이터베이스에 flush 할 당신 자신의 동기화 지점을 정의하라.

5. 당신의 캐쉬 전략을 빨리 정의하라 : transactional 데이터를 캐쉬할 것인가? 만약 그렇다면, www.tangosol.com 로 가서 그들의 제품, Coherence를 사라. 만약 당신이 단지 모든 클러스터 멤버들에 대한 유효한 변화들 사이의 다소 작은 시간지연 현상이 있는 부분에서 lookup/setup 데이터만을 캐쉬할 생각이라면, 당신은 OSCache 와 같은 오픈소스만으로도 충분할 것이다. transactional 캐쉬는 매우 선호되는데, 이것은 당신으로 하여금 캐쉬가 가진 엄청난 파워라고 할 수 있는 쿼리 캐쉬를 사용할 수 있게 해준다. 나는 non-transactional 캐쉬를 쿼리 캐쉬의 목적으로 사용하는 사람들과 말을 해 본 적이 있는데, 하이버네이트 문서와 Gavin 은 그런 방법이 안전하지 못하다고 말한다. 그것은 아마도 99.9%의 시간동안 작동할 것이지만, 그러나...(역자주:0.1%의 불안함이 있다는 듯?) 쿼리 캐쉬는 비록 transactional 캐쉬가 없이 non-transactional 데이타에 대한 쿼리들만 캐쉬하더라도 유용할 것이다.

6. 당신의 엔터티들을 캐쉬하라, 그리고 그 캐쉬 세팅들을 연관된 매핑들(set, map, bag, list)에 잘 적용하는지를 확인하라.

7. 당신은 엔터티를 오로지 그것의 일대다 혹은 다대다 관계에 있는 것과 조인할 수 있다. 때문에 올바른 것을 선택해야만 한다. 당신이 eagerly 로드하기를 원하는 다른 컬렉션들의 배치 사이즈(한 번에 가져올 연관된 레코드들의 숫자)에 대한 적절한 값을 세팅하라.

8. 당신의 엔터티들에 대한 레퍼런스들이 어디에서도 가비지 컬렉션을 방해하고 있지 않음을 확신하기 위해 object 그래프를 검사하라. 이것은 많은 관계를 가지고 자주 변경되는 엔터티들에게는 정말로 중요한데, 왜냐하면 메모리를 채워버릴 많은 objects가 있기 때문이다.

9. 만일 가능하다면, 버전 컬럼을 가지고 있는 optimistic concurrency를 사용하라. Timestamps 역시 동일한 방식으로 작용하지만, 깔끔하진 않다. 하이버네이트가 레코드 변경여부를 확인하기 위해 모든 값을 검사하도록 해선 안된다.

10. identifier 생성의 생명주기를 이해해야 한다. 만약 당신이 시퀀스나 다른 데이터베이스 생성 identifier 를 사용한다면, 당신의 identifier 는 새로운 엔터티가 데이터베이스에 저장될 때까지 부여되지 않을 것이다. 만약 당신이 identifier를 당신의 equals() 와 hashCode() 구현체의 일부분으로 사용한다면, 만약 당신이 엔터티를 저장하기 전에 Set 에 담는다면 당신은 저장된 후에 다시 찾을 수 없을 것이다. 나는 이러한 이유에서 엔터티 인스턴스의 생성자에서 할당된 UUIDs 를 사용해왔으며 그것은 삶을 좀 더 쉽게 만들어주었다. 나는 이러한 문제에 직면한 몇몇 사람들에 대해 얘기 들어왔는데, hashCode() 구현이 엔터티의 모든 인스턴스에 대해 똑같은 숫자값을 항상 반환한다는 것이었다. 기술적으로 hashCode()를 실행하는 동안은 이것은 결코 최적이 될 수 없다.

11. 하이버네이트를 trace할 수 있도록, 당신의 IDE 에 당신이 사용하고 있는 배포판에 들어 있는 하이버네이트 소스 코드에 대한 참조를 세팅하라. 이것은 당신이 보고 있는 동작을 유발하는 것에 대한 이해를 도와줄 뿐 아니라, 당신이 하이버네이트가 어떻게 동작하는지에 대해서 이해할 수 있도록 해준다.

12. 두번째 레벨 캐쉬에 대해 이해하라. (그리고 세션은 당신의 첫번째 레벨 캐쉬에 있음을 이해하라.) 이것이 당신의 엔터티 데이터를 캐쉬하는 방법(field 값들의 배열에 대한 identifier의 맵 형식)과 컬렉션들(이것은 단지 identifiers를 저장하고 엔터티 캐쉬로부터 객체들을 새로 구성한다.)에 대해 이해하라.

13. Hibernate in Action 을 가서 사도록 하라. 이 책은 하이버네이트 2.1 을 다루고 있지만 기본적인 개념은 같으며 3.0 에서는 몇가지 새로운 특징들이 추가되었다.

14. 새로운 특징들을 말해보자면, 필터를 살펴보도록 하라. 나는 이전에 필터를 사용할 기회가 없었는데, 그것들이 유효 날짜 문제(effective date problem)를 매우 쉽게 만든다는 단순한 사실이 굉장한 이점(huge win)을 가져다 주었다. 필터는 전체를 로드하지 않고도 당신이 컬렉션 같은 것에서 많은 레코드들을 찾을 수 있게 해준다. 굿이다.

15. 이제 시작하기 위해 당신의 첫번째 할 일은 메모리와 CPU 프로파일러와 IronTrack SQL 과 같은 SQL 프로파일러 역시 설치하는 것이다. 그리고, 모든 설정들을 꼬아놓고 프로파일러를 사용하면서 당신의 테스트 케이스들을 새로 동작시키고 어떤 효과가 있는지 지켜보도록 하라.

참고문서


Site running on a free Atlassian Confluence Open Source Project License granted to JavaJiGi Project. Evaluate Confluence today.
Powered by Atlassian Confluence, the Enterprise Wiki. (Version: 2.3.1 Build:#643 1월 22, 2007) - Bug/feature request - Contact Administrators