You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 62 Next »

JPA는 SQL문을 통해 어플리케이션을 작성했을때보다, 수많은 귀찮은 일을 하지 않아도된다는것을

실습을 통해 파악을 하였습니다. 하지만 실제 그것이 어떠한 SQL문을 수행하는지

또한 그 SQL문이 성능적으로 문제가 없는지 데이터베이스를 병행해서 공부해야하는 과제가 있습니다.

실행계획을 예상하고 측정하는것은 아주 광범위한 주제입니다.

데이터베이스를 공부했을때 성능에 관련된 실행계획은 SQL과 더불어 JPA에서도 이해해야하는 항목으로 생각됩니다.

실행계획 고려하기

SQL문을 해석하고 , 원하는 데이터 집합을  IO에서 빠르게 가져오기위한 노력으로

DB엔진은 구문분석후 효과적인 결과를 내기위해 실행계획을 세우게 되며

이것은 각각의 데이터베이스마다  차이가있습니다.

SQL문에서 이러한 실행 계획에대한 옵션을 직접 할수 없을뿐더러, 전적으로 DataBase에게 위임하게 됩니다. 

즉, JPA도 이러한 실행계획에 관여할수 없으며 이러한 실행계획을 확인하는 방법은 SQL문을 실제

실행하여 어떻게 작동되는지 확인하는것입니다.

이름명령어
Oracleset autotrace traceonly
MSSQLSET SHOWPLAN_TEXT_ON
DB2EXPLAIN ALL WITH SNAPSHOT FOR SQL 구문
PostreSQLEXPAIN SQL 구문
MySQLEXPLAIN SQL 구문


JPA Query Method TO SQL

JPASQL

studentList = findByGroupInfoName("학생")

SELECT * FROM user ui left join spring.group_info gi

on gi.group_id = ui.group_id and gi.name="학생"

JPA에 익숙하다면, 자신이 작성한 함수 인터페이스가,

어떠한 SQL문으로 변환되어 작동이 될지  예측할수도 있지만, JPA를 믿지 못하겠다고 가정해봅시다.

이럴때 아래옵션을 통해, 함수호출시마다 SQL문을 확인할수가 있습니다.

이것을 켜는 이유는 JPA가 어떠한 엉뚱한 SQL문을 만들어낼지?

불필요하게 중복호출을 하지 않는지?(사실 이게 가장 중요합니다.)  또는 그 SQL문이

제대로된 실행계획을 가지고 실행이되는지 검증을 하기 위함입니다.


JPA-SQL문 Trace

  • spring.jpa.properties.hibernate.show_sql=true
  • spring.jpa.properties.hibernate.use_sql_comments=true
  • spring.jpa.properties.hibernate.format_sql=true


어플리케이션의 JPA테스트코드와 SQL 실행을 Trace한 예

 JPA를 통해 작성된 인테페이스를 통해 어플리케이션에서 작동되는 실제 쿼리를 수행을 간단하게 할수가 있으며

어플리케이션 레벨에서 쿼리에관련된 TestCase 작성을 쉽게하고 또한 실제 작동되는 SQL문도 체크할수 있습니다.

소모적 반복적 SQL문 작성시간을 줄이고, 수많은 케이스를 유닛테스트로 전환될수 있을 가능성을 확인할수 있으며

이것은 데이터중심에서 메시지중심으로의 설계를 가능하게합니다. 


MS를 사용한 개발 진영 SQL은 SP를통한 통제 방식이 개발이 권장이 아니라 정책적 변경불가한 요소인곳도 많이 봐왔으며

MS권장방식이라고 믿고 계신 DBA분들도 많이 봐왔으며, 아주 오랜전 결정된 정책( 그때 정책을 만든사람은 아무도 없음)

에 대한 이해및 히스토리가 대부분 없는 경우도 많으며 이것을 다시 셋팅하는것은 거의 쿠테타에 가까운것이였습니다.

사실 MS는 JAVA오픈진영보다 훨씬더 빠르게 ORM을 통한 개발 요소를 내부에서 표준화하였고 통합하였습니다. -Entity FrameWork

그래서 어플리케이션 개발자가 ORM적용을 주도하려면 DB개발지식을 가지고 토론해야하기때문에 불편해지는 상황이 생길수 있습니다.


이것을 힘들게 주도하여 바꾸는것을 권장하지 않습니다.

언젠가 쓰일수 있으며, 왜 ORM은 우리회사에 적용이 어려운가란 주제는

RDB를 공부하는데 아주 좋은 주제가 될듯 합니다.



다음은 ORM 사용시 오해받는 몇가지 주제입니다.

  • ORM의 쿼리는 통제가 안되고 느릴것이다. ==> TypeSafet한 방식의 쿼리빌드를 선택하고,표준쿼리를통해 성능문제를 해결하려고 합니다.
  • ORM에서는 쿼리 최적화가 불가 ==> 네이티브 쿼리의 불편한점에대해 경고를 해줄뿐 JPA에서 날쿼리도 가능합니다.
  • ORM은 쿼리 개발을 모르는 초짜가 사용하는 기술이다. ==> QueryDSL은 SQL을 이해못하면 람다식으로 SQL식을 풀어낼수 없으며, 쿼리작성보다 엔티티를 먼저 맞추는데 시간을 들입니다. 그리고 쿼리식과 람다식은 닯아있습니다. ORM에서 오히려 순차적 중복 쿼리 호출방식을 지양합니다.
  • ORM은 ERD를 그려낼지 모르는 개발자가 사용하는 기술이다 - ==> 기존개발방식이 ERD를 모르고 날쿼리로 잘못된 집합체로도 뷰어개발이 가능하지만, ORM에서 ERD관계를 맞추지못하면 빌드 조차 안됩니다.


DB용어를 사용하여 조급더 고급지게 접근해보겠습니다.

  • DDL(Data Definitison Language)의 테이블 객체의 생성(Create),변경(Alert),삭제(Drop)등을 수행
  • DML(Data Manipulation Language) : 스키마객체의 데이터를 Insert/Update/Select등을 할수 있는 명령어(표준화되어있어서 거의 공통)
  • DCL(Data Control Language) : Commit,RollBack,SavePoint등을 할수 있는 명령어(DB종속적인 경우가 많음)

JPA-ORM은 기본적으로 DDL/DML/DCL을 모두 할수 있는 구조입니다.

이것은 ORM이해가 아닌 기존 RDB가가진 언어입니다. 접근 정책정의에 있어서 중요요소 3가지를

빠트리고 이야기가 진행되는경우가 많지만... 정책결정은 위 3가지를 포함해서 이야기되어야하는 항목으로 생각됩니다.


SP를 이용한 장점:

  • SP를 통한 통제방식은 MSSQL과 상관없이 , DB접근 정책을 정하기 아주 단순/명쾌 해지기 때문입니다.
  • 또한 쿼리품질을 SP를 통해 제어하고, 비지니스로직을 집합시키는데 용이합니다.
  • 결국 DDL/DML/DCL 어플리케이션별로 세부적인 접근 정책이 필요없어지게 됩니다.
  • 그리고 쿼리최적화를 통한 SP호출방식이 실행계획 성능 향상에 일반적으로 도움이 된다.


ORM을 이용한 장점:

  • 고성능 분산처리 어플리케이션 설계를 위해서는 DML 특히 트랜잭션에 관련된 DCL이 가능해야함 ( Entity의 영속성및 Proxy개념 )
  • SP내부에 작성되는 쿼리는 일괄적인 품질관리가 안되며, SP자체가 형상관리가 안되고 결국 SP는 이야기합니다. 나는 안쓰인다 고로 존재한다.
  • 고성능 분산처리를 위해 트랜잭션에 어플리케이션이 안정적이고 더 효율적이게 관여할수 있는 개발방법이 많이 등장하였습니다.
  • 인덱스를 걸고 실행계획을 안정적으로 유지하는것은 DBMS마다 약간의 차이가있고 그리고 그것은 비표준 SQL문 작성을 강요하며 일괄적으로 유지가 어렵습니다.


SP를 통한 DB개발에서 이야기하는 장점이 오늘날에는 단점이 된 케이스가 일부있고

서로 상반된 이야기를 하기때문에 풀어나가기가 어려운 주제임은 분명합니다.


실행계획 조사하기

Trace된 SQL문을 그대로 복사하여, 실행계획을 조사합니다. 매번 이러한 과정을 거칠필요는 없을듯보이며

SQL방식이던 JPA방식이던..., 성능에 의심이가는 부분에대해서는 개발방식과는 별개로 측정되고 분석되어야하는

사항입니다.


실행계획 콘솔모드

실행계획 시각화

참고:DB Management Tool에 따라서 실행계획 시각화기능을 제공하기도합니다.(MSSQL)


실행계획의 출력포맺은 DB마다 다르지만 공통적인 요소가 있습니다.

  • 조작대상 객체
  • 객체에 대한 조작의 종류
  • 조작 대상이 되는 레코드 수
  • 호출 계층


순차 풀스캔 VS 인덱스 스캔

엔티티의 설계

@Entity
public class User {
	private String name;

	@ManyToOne
	@JoinColumn(name = "GROUP_ID",nullable = true)
    private GroupInfo groupInfo;
}
ManyToOne은 JPA에서 관계도 형성을 하는 어노테이션으로서 실제 데이터베이스에서는
아래와같이 테이블생성시 외래키 설정및 인덱스 설정이 자동으로 수행되게 됩니다.
KEY `FKa36i4ekojwk70bxen390i6tek` (`group_id`) USING BTREE,
 CONSTRAINT `FKa36i4ekojwk70bxen390i6tek` FOREIGN KEY (`group_id`) REFERENCES `group_info` (`group_id`)

순차풀스캔

JPASQL
findByName("Minsu")SELECT * FROM user where name = 'minsu2';

Name필드에는 아무런 인덱스가 없기때문에, minsu2를 찾기위해 순차적으로

끝까지 조회를 해야합니다. (중복 사용자포함)

데이터량이 많아질시 탐색시간이 같이 선형적으로 증가합니다.


인덱스 스캔

JPASQL
findByGroupId(1)SELECT * FROM user where group_id = 2;

인덱스가 설정된 필드는, 이미 특정 탐색 알고리즘을 위해 데이터 분류가 되어 있습니다.

이경우 모두 순차 비교검사 할필요는 없이, 탐색 회수를 줄일수 있습니다.

적은량의 데이터에서 탐색시 효과가 없을수 있으나,  데이터량이 늘어남에따라 효과를볼수가 있습니다.

인덱스가 걸려있다고 항상 인덱스 스캔이 되는것은 아닙니다.

원하는 데이터를 뽑기위해 SQL문은 더 복잡해질수 있으며 실행계획은 DBMS가 세우며

옵티마이져 통계에의해  어떠한 테이블에서 풀스캔이 더 효율성이 좋다고 판단되면

인덱스를 무시하고 풀스캔이 진행될수도 있습니다. 이것은 실행계획을 조사하면

나오는 Tip으로 (Mysql은 Extra) 알수가 있습니다.


인덱스 최상위 Type은 페이지 물리적 재배열여부에따라 클러스터와 논클러스터로 나뉠수 있으며

동일 데이터라고 해도 스캔의 횟수가 달라질수 있습니다.

클러스터 인덱스 VS 논클러스터 인덱스
비교클러스터 인덱스논클러스터 인덱스
차이물리적으로 행을 재배열물리적으로 재배열 하지않음
스캔 방식

페이지크기작음큼
선택도
  • 30% 이내에
  • 키값이 이미 페이지단위로 정렬이 된상태이기때문에 7,8,9를 찾기위해 IO접근 1번발생
  • 3%이내
  • 7,8,9를 찾기위해 페이지 2,3를 두번 접근하는 IO 발생



페이지 논리갯수테이블당1테이블당 249

지정방법

(DB마다 다를수있음)

PRIMARY KEY에서만 사용될수 있습니다.

정정: 테이블당 유니크한키로 한번만 지정가능합니다. PRIMARY KEY에 걸려버렸다고

치면...이후 다른키에 또 걸수 없습니다.


( 기본이냐 옵션이냐의 차이는 DB마다다름)

명시해서 지정
키의이점

데이터 값의 범위가 크며, 키에따른 Order규칙이

키가 조인에 자주사용됨


장단점
  • 조회수가 수정수보다 월등히 많을때
  • 빈번한 업데이트에서 재인덱싱이 일어나기때문에 분리
  • 데이터 추가에따른 인덱싱페이지의 구조변화가 없기때문에 데이터 추가에 유리
  • 데이터량이 많아짐에따라 인덱스페이지가 파편화되기때문에 검색은 불리해질수 있음








선택도와 실행계획의 분리 추가 참조사이트

스캔 범위/방식에따른 실행계획 전략

성능을 위한 스캔 범위 Type은 3가지정도로 요약할수 있습니다.

  • 이중루프(Nested Loops) : 한쪽테이블을 읽으면서 결합조건에 맞는 레코드를 다른쪽에서 모두 찾음
  • Sort Merge : 결합할 두 테이블을 정렬을 하고 순차적으로 결합
  • Hash : 결합 키값을 해시로 맵핑


어느것이 항상빠르며,실행계획이 고정이된다라고 볼수 없으나

Sort Merge가 되는방식이 일반적으로 성능에서 안정적입니다.(편차가 크게 없이 빠름)


스캔범위및 실행 계획이 복잡해지지 않게 하기 위한 가장 간단한 규칙이지만,

우리가 원하는 집합을 만들다보면 이 규칙을 깨트리기 쉽고, 쿼리능력자에따라 차이가 날수있습니다.

  • 스캔 범위 줄이기
  • 조인을 덜 복잡하게 만들기

참고 : https://community.modeanalytics.com/sql/tutorial/sql-performance-tuning/



우리가 원하는 집합을 만들기위해, 2개의 테이블만 조작하여 JOIN문을 사용하면 좋겠지만

실제는 그렇지 않습니다. 

JPA 튜닝 포인트

JPA에서는 실행계획이 틀어지고, 예측하기 어려운 튜닝포인트를 쿼리가 아닌

OOP중심, 즉 어플리케이션서 관여할수 있는 계층을 하나더 추가하였습니다.


JPA에서 이루어지는 성능에 관련된 기능을 간단하게 설명을하면...

User user1 = findByName("Minsu");
User user2 = findByName("Minsu");
user1.GetName()
user2.GetName()

위와같은 코드는 일반적인 SQL/SP 호출 어플케이션에서는, 두번의 Select문을 DB에게 요청을 하였을것입니다.

JPA에서는 , 동일 트랙잰션에서 위와같이 동일처리라고 판단되는 사항에대해

SELECT SQL한번만 조회를하고, DB 호출없이 오브젝트 재사용전략을 택합니다.

DB에서는 상황에따라 옵티마이져가 불필요한 IO를 접근하지 않고, 메모리를 재활용할수 있는 상황입니다.

JPA 어플리케이션 레이아웃에서는, SQL호출 자체도 하지 않겠다는 의미입니다.

SQL호출을 하지 않는다란 말은 다음과정이 내포되어있기때문에 호출횟수에따라 아주 큰 비용이 될수도 있습니다.

SQL문요청 → 네트워크 전송 → DB엔진이 구문분석 → IO Read → 네트워크로 결과 반환 

JPA의 이러한 캐시처리같은 메카니즘이 사용 중복 호출실수를 잡으려고 이렇게 작동되는것은 아니며

어플케이션 레이아웃에서 관여할수있는 성능에 관련된 몇가지 JPA컨셉을  추가로 학습을 해야합니다.

매번 SQL문을 호출하고 즉시 답을 얻는 방식과 달리, 아래와같은 몇가지 컨셉이 존재합니다.


Read전략

  • 즉시읽기( Eager loading) : 
  • 지연읽기 ( Lazy loading ) :

영속성 전이 전략

  • ALL : 부모의 변화가 자식에게 모두 전가
  • PERSIST : 부모의 영속화 될때 자식도 영속화가됨
  • MERGE : 트랜젝션이 종료되고 변경사항이 merge()수행시 변경사항적용
  • REMOVE : 부모삭제시 연관된 자식도 삭제
  • REFRESH : 부모가 변경되면 자식도 변경
  • DETACH : 부모가 DETACH되면, 연관된 ENTITY도 DEATCH되어 변경반영 죽시 안됨
  • orphanRemoval : 연관관계가 끊어진 자식을 자동으로 제거


JPA는 객체지향과 데이터모델링 사이에 간극을 최소화하고 편리한 방식임에는 분명하지만

개발 난이도를 줄였다라고 판단할수는 없을듯 합니다. 

오히려 SQL/SP 중심적으로 개발했을때는 신경쓰지 못한 부분에대해

더 깊이 RDB를 이해하고 JPA의 추가적인 영속성 특성을같이 잘 활용해야 사용측면에서도

성능 측면에서도 실무에 적용이 될것으로 기대해봅니다.


논란의 소지가 있지만, JPA를 학습하면서 느낀점입니다.

  • JPA(ORM)은 SQL문을 모르고 RDB를 이해못해도 편리한 개발을 하기위해서 존재하는것이 아니다.
  • 객체관점에서 데이터를 접근하려면 ERD를 완전하게 이해하고 그것을 Entity에 반영을 해야한다.
  • 선행단계가 되고나면.., 반복적인 SQL문작성을 안해도되기때문에 좀더 디테일한 메시지 중심 설계가 가능해진다.
  • MyBatis를 ORM이다라고 정의할수도 있지만, 정확하게 JAVA ORM 표준 스펙에 들지 않는다. ( ORM이아닌 SQLMapper라고 정의하기도합니다.)


SPRING BOOT를 통해 자연스럽게 JPA를 권장해서 접근이 쉬운기술이다라고 오판을 하였지만

기존에는 일반적으로 성능의 대부분의 문제를 쿼리튜닝및 데이터중심적 설계로 해결을 하였습니다.

하지만 ORM에서 성능문제는 어플리케이션에서 OOP의 영속성을 관리해야하며 최종 RDB에 저장되기때문에

성능 해결포인트가 다른곳에 있으며 이것을 이해하는것은 RDB와 JPA내부에서 작동되는것을 둘다 알아야됨을 의미합니다.

http://wonwoo.ml/index.php/post/997



이 부분은 개념과함께 구체적인 사용사례가 필요한 부분이며, 샘플을 좀더 준비할예정입니다.



  • No labels