Page History
Info |
---|
JPA는 SQL문을 통해 어플리케이션을 작성했을때보다, 수많은 귀찮은 일을 하지 않아도된다는것을 실습을 통해 파악을 하였습니다. 하지만 실제 그것이 어떠한 SQL문을 수행하는지 또한 그 SQL문이 성능적으로 문제가 없는지 데이터베이스를 병행해서 공부해야하는 과제가 있습니다. 실행계획을 예상하고 측정하는것은 아주 광범위한 주제입니다. 데이터베이스를 공부했을때 성능에 관련된 실행계획은 SQL과 더불어 JPA에서도 이해해야하는 항목으로 생각됩니다. |
...
이것은 데이터중심에서 메시지중심으로의 설계를 가능하게합니다.
SQL문은 약간의 조건만 바뀌어도 쿼리를 새롭게 작성해야하며( 똑똑한 공통 SQL빌드가 없다고 가정)
그리고 약간의 기능차이로 인해 매번 새로운 SP를 DBMS에 등록하고 관리해야합니다.
형상관리가 비교적 쉽지 않은 SP를 장기간 운영하면, 심각하게는 30%이상이 사용되지 않는 코드가되며
그누구도 사용되지 않는 코드를 정리하지 못한채 존재하게 됩니다.
...
title | ORM사용의논쟁 : 주관및 픽션이반영되었습니다. |
---|
JPA가 직접 SQL문을 수행합니다. 여기서 수많은 논쟁이 발생할수 있습니다.
- A : SQL문을 어플리케이션에서 Type세이프(QueryDSL)하고 효율적인 방법으로 사용할수 있는 방법을 도입하였으며 DB호출을 방지하기위해 분산처리시켰습니다. 그런데 작동을 안합니다.
- B: 직접쿼리는 쿼리튜닝에 관여할수 없으며 DBMS에서 관리할수 없으니, SELECT 권한이 없습니다.어플리케이션은 SP로만 사용해주세요 SP방식이 무조건 성능이좋습니다.
- A : 운영 데이터가 꼬인것같습니다. A,B테이블에서 X조건이되는 게 문제인듯보입니다. 다른사람이 만든 SP에서 뭔가 잘못된거같습니다. 데이터 검증부탁드립니다.
- B: 여러개발자의 SP개발 문제에 관여하기 어렵습니다. 직접 문제를 찾으십시오
- A : 형상관리가되는 어플리케이션을 통해 문제를 자동으로 찾고싶습니다. 어플리케이션에 Select권한을 주십시오
- B: 정책상 어플리케이션이 쿼리를 하면 안됩니다. 운영처리해야하니... 개인계정을 추가하고 임시 Select권한을 드릴테니 직접 문제를 찾으십시오
- A: 이문제를 찾는 SP를 작성하였습니다. 직접 호출하여 문제를 분석할테니 개인에게 SP실행권한을 주십시오
- B: 정책상 개발자에게 SP 실행권한을 줄수 없습니다. 정상 디플로이된 어플리케이션을 통해 실행하십시오
개발자가 직접 운영DB에 접근을 해야하는 문제와 ,어플리케이션은 SP로만 작성되어야한다란 문제에서 충돌 과정입니다.
다소 극단적으로 상황을 만들어 냈지만.....이것은 DBMS의 차이로 정책이 그렇게되어야 한다고 결론내리는 DBA분도 계십니다.
대략정리하면 MSSQL은 SP방식이 올바르고, 오라클은 SP안쓰는게 이득이다란 결정입니다.
하지만 전통적인 개발방식에서 그렇게 진행 되어 왔던것이며, DBMS의 차이는 아닙니다.
- MS개발진영에서는 SP를 관리하는 방식및 SP호출을 통한 개발통제방식으로 진행되어왔습니다. 배치는 DBMS스케쥴러의 SP방식을 고수했습니다.
- 오라클에서는 성능개선점을 쿼리튜닝에 포인트를 좀더 두었고, 배치처리는 SP가아닌 SQL을통한 어플리케이션 스케쥴에의한 부분처리방식을 택하였습니다.
그래서 어플리케이션에서 MSDB를 선택하면 SP를 사용해야하고 오라클을 사용하면 쿼리방식을 사용한 국내에서만 해당되는 관례일뿐입니다.
심지어 오라클은 SP를 사용할수 없고 , 오라클에서 SP는 아무 이득이없다라고 잘못생각하시는분도 많이 봐왔습니다.
SP를 사용한 개발의 장단점은 MSSQL이나 오라클이나 별반 차이가 없다란 것입니다.
SP개발방식또는 쿼리방식이 각각 자신의 개발팀및 DB유지차원에서 그때당시 가장 적합하다라고 판단한 로컬 정책일뿐입니다.
결코 오라클이나 MS가 결정한 사항이 아니란것입니다. 그리고 그 정책의 장단점은 현시점 맞지 않을뿐더러
그냥 현존하는 DBA가 전통적으로 유지했던 개발방식에 맞춰 DB를 그렇게만 관리했기때문에 바꾸기가 힘들다라고 정의를 해봅니다.
이것은 데이터중심적 개발적 방식도 아니고 DBA중심적 개발방식을 택하고 있다란 사실을 인지하는것입니다.
그럼 과연 MS에서는 SP방식을 제안하고 추천하였는지?
SP개발방식이 절대적으로 유리한지 MS 웹플랫폼에 사용되어지는 DB기술을 한번 살펴볼 필요가 있습니다.
Entity FrameWork : 궁극적으로 ORM을 추구하는 자바진영의 JPA/Hibernate 와 같은 녀석
EnterPrise Library: SQL/SP을 맵핑을 하는 JAVA의 Mybatis버젼
LINQ : JAVA의 QueryDSL에 대응
위 스펙은 모두 MS가 공식적으로 지원하고 있는 기술이며 최신 기술도 아닙니다.
MSDN에 있는 내용들이며..., ORM과 상관없이 Asp.net 개발하면서 자주 눈에 뛰었던 라이브러리들입니다.
JAVA에 비해 MS에서의 ORM 추가 사용은 아주 쉽다란것이며
JPA+QUERYDSL의 오픈진영과 다르게 MS가 주도적으로 LINQ와 함께10년전부터 ORM과 함께 외쳐왔던 기술입니다.
각각 진영의 ORM의 표준정립은 MS가 먼저 하였다란것입니다. 이것은 단지 오픈진영의 표준이 오래걸리는것의 차이일뿐이며
해외진영 엔터프라이즈급 웹에서는 JAVA의 ORM이 꾸준하게 성공을 거두고 있다란 것입니다.
기존에 운영중인 플랫폼을 굳이 무리해서 바꿀필요는 없지만, 만약 바꾸게 된다고 하면 JAVA↔C# 또는 ASP.net↔Spring 으로
전환하는것은 아무런 의미가 없습니다. 본질적으로 동일한 웹기술을 서로 가지고 있으며 ,
개발팀이 더 잘할수 있는 방식을 사용하면 됩니다.
하지만 기존 쿼리중심 개발방식에서 ORM방식으로 바꾸는것은 웹에서는 개발 플랫폼을 바꾸는 것보다
더큰 모험이 될것이며 가치가 있는 도전이 될것입니다.
...
실행계획 조사하기
Trace된 SQL문을 그대로 복사하여, 실행계획을 조사합니다. 매번 이러한 과정을 거칠필요는 없을듯보이며
...
성능 측면에서도 실무에 적용이 될것으로 기대해봅니다.
이 부분은 개념과함께 구체적인 사용사례가 필요한 부분이며, 샘플을 좀더 준비할예정입니다.
...
논란의 소지가 있지만, 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
Expand | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| |||||||||||||||||||
|
...
|