Page History
Info |
---|
JPA는 SQL문을 통해 어플리케이션을 작성했을때보다, 수많은 귀찮은 일을 하지 않아도된다는것을 실습을 통해 파악을 하였습니다. 하지만 실제 그것이 어떠한 SQL문을 수행하는지 또한 그 SQL문이 성능적으로 문제가 없는지 데이터베이스를 병행해서 공부해야하는 과제가 있습니다. 실행계획을 예상하고 측정하는것은 아주 광범위한 주제입니다. 데이터베이스를 공부했을때 성능에 관련된 실행계획은 SQL과 더불어 JPA에서도 이해해야하는 항목입니다항목으로 생각됩니다. |
Table of Contents |
---|
실행계획 고려하기
...
이것을 켜는 이유는 JPA가 어떠한 엉뚱한 SQL문을 만들어낼지?
불필요하게 중복호출을 하지 않는지?(사실 이게 가장 중요합니다.) 또는 그 SQL문이
제대로된 실행계획을 가지고 실행이되는지 검증을 하기 위함입니다.
...
어플리케이션 레벨에서 쿼리에관련된 TestCase 작성을 쉽게하고 또한 실제 작동되는 SQL문도 체크할수 있습니다.
소모적 반복적 SQL문 작성시간을 줄이고, 수많은 케이스를 유닛테스트로 전환될수 있을 가능성을 확인할수 있습니다.있으며
이것은 데이터중심에서 메시지중심으로의 설계를 가능하게합니다.
실행계획 조사하기
Trace된 SQL문을 그대로 복사하여, 실행계획을 조사합니다. 매번 이러한 과정을 거칠필요는 없을듯보이며
SQL방식이던 JPA방식이던..., 성능에 의심이가는 부분에대해서는 개발방식과는 별개로 측정되고 분석되어야하는
사항입니다.
실행계획 콘솔모드
실행계획 시각화
참고:DB Management Tool에 따라서 실행계획 시각화기능을 제공하기도합니다.(MSSQL)
실행계획의 출력포맺은 DB마다 다르지만 공통적인 3가지요소가 요소가 있습니다.
- 조작대상 객체:
- 객체에 대한 조작의 종류
- 조작 대상이 되는 레코드 수:
- 호출 계층
순차 풀스캔 VS 인덱스 스캔
엔티티의 설계
Code Block | ||||
---|---|---|---|---|
| ||||
@Entity public class User { private String name; @ManyToOne @JoinColumn(name = "GROUP_ID",nullable = true) private GroupInfo groupInfo; } |
...
인덱스가 걸려있다고 항상 인덱스 스캔이 되는것은 아닙니다.
원하는 데이터를 뽑기위해 SQL문은 더 복잡해질수 있으며 실행계획은 DBMS가 세우며
옵티마이져 통계에의해 통계에의해 어떠한 테이블에서 풀스캔이 더 효율성이 좋다고 판단되면 풀스캔을 할수도
인덱스를 무시하고 풀스캔이 진행될수도 있습니다. 이것은 실행계획을 조사하면
나오는 Tip으로 (Mysql은 Extra) 알수가 있습니다.
인덱스Type은 인덱스 최상위 Type은 페이지 물리적 재배열여부에따라 클러스터와 논클러스터로 나뉠수 있으며
동일 데이터라고해도 데이터라고 해도 스캔의 횟수가 달라질수 있습니다.
클러스터 인덱스 VS 논클러스터 인덱스
비교 | 클러스터 인덱스 | 논클러스터 인덱스 |
---|---|---|
차이 | 물리적으로 행을 재배열 | 물리적으로 재배열 하지않음 |
스캔 방식 | ||
페이지크기 | 작음 | 큼 |
선택도 |
|
|
최대갯수페이지 논리갯수 | 테이블당1 | 테이블당 249 |
지정방법 (DB마다 다를수있음) |
정정: 테이블당 유니크한키로 한번만 지정가능합니다. PRIMARY KEY에 걸려버렸다고 치면...이후 다른키에 또 걸수 없습니다. ( 기본이냐 옵션이냐의 차이는 DB마다다름) | 명시해서 지정 |
키의이점 | 데이터 값의 범위가 큼크며, 키에따른 Order규칙이 키가 조인에 자주사용됨 | |
장단점 |
|
|
스캔 범위/방식에따른 실행계획 전략
...
- 이중루프(Nested Loops) : 한쪽테이블을 읽으면서 결합조건에 맞는 레코드를 다른쪽에서 모두 찾음
- Sort Merge : 결합할 두 테이블을 정렬을 하고 순차적으로 결합
- Hash : 결합 키값을 해시로 맵핑
어느것이 항상빠르며,실행계획이 고정이된다라고 볼수 없으나
Sort Merge가 되는방식이 일반적으로 성능에서 안정적입니다.(편차가 크게 없이 빠름)
스캔범위및 실행 계획이 복잡해지지 않게 하기 위한 가장 간단한 규칙이지만,
...
우리가 원하는 집합을 만들기위해, 2개의 테이블만 조작하여 JOIN문을 사용하면 좋겠지만
실제는 그렇지 않습니다.
...
JPA 튜닝 포인트
JPA에서는 실행계획이 틀어지고, 예측하기 어려운 튜닝포인트를 쿼리중심에서쿼리가 아닌
OOP중심, 즉 어플리케이션서 관여할수 있는 계층을 하나더 추가하였습니다.
JPA PROXY/영속성 전이등을 사용하여, 어플리케이션 자체에서
DB접근을 최소화하는 전략을 택할수 있습니다. 이러한것을 사용한다고
- SQL문에따라 달라지는 같은 결과 다른 실행계획
- 테이블의 생성 옵션/데이터량에 따라 달라지는 검색,업데이트 속도
이러한 것을 무시할수 있는게 아닙니다. 더 공부해야 합니다.
JPA의 성능에 관련된 기능들은 JPA가 RDB를 잘 이해하고 있어서 사용할수
있는 기능이며, 역설적으로 추상화된 기능을 사용하려면 RDB가 가진 본질을
더 잘 이해해야합니다.
JPA에서 이루어지는 성능에 관련된 기능을 간단하게 설명을하면...
...
성능 측면에서도 실무에 적용이 될것으로 기대해봅니다.이부분은 좀더 구체적인 예로 다시 설명할 예정입니다.
이 부분은 개념과함께 구체적인 사용사례가 필요한 부분이며, 샘플을 좀더 준비할예정입니다.
Expand | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
|