Transaction(트랜잭션) VS Procedure(프로시져)

[강동욱]

사실 프로시져는 많이 사용해보지 못했습니다. 금융이나 은행권에서 사용한다는 이야기만 살짝 들었을 뿐...

제가 하는 일에서는 중복쿼리의 원자성만 유지하면 됬기 때문에 트랜잭션만으로 충분했었거든요.

그래서 혹시 프로시져에 대해 잘 아시는 분 계시면은 답변 부탁드립니다.

지금 제가 아는 지식으로는 트랜잭션을 이용하면 동일한 원자성을 가진 2개 이상의 쿼리를 Java 코드 상에서 컨트롤이 가능할
수 있다는 점이고

프로시져는 동일한 원자성을 가진 2개 이상의 쿼리를 데이터베이스 상에서 처리하는 방식이라고 이해하고 있거든요.

속도면에서나 활용도 면에서나 어느 쪽이 더 유익한 지는 아직 잘 모르겠습니다.

제가 잘 알고 있는지도 확실치 않구요 ^^;;

두가지 중 어느 것이 더 나은지... 아니면 장단점이 무엇인지... 좀 알려주세요 ^^;

[최영목]

" 지금 제가 아는 지식으로는 트랜잭션을 이용하면 동일한 원자성을 가진 2개 이상의 쿼리를 Java 코드 상에서 컨트롤이 가능할
수 있다는 점이고"

여기서 말씀하시는 원자성이 원자성 트랜잭션(업무단위 트랜잭션, all or nothing)이라면 EJB나 스프링 등으로 가능합니다.

개인적인 생각으로는 프로시저의 경우 2PC가 아닌 상황에서만 사용할 수 있고, 오로지 성능때문에 쓰는 것이지 가독성, 유지보수성, 트랜잭션 관리 측면 등에서 애플리케이션서버에서 제어하는 것이 더 낫다고 생각합니다.

ps. 현재 업계1위 화재보험사에서 플젝 진행중인데 SP쓰는 것은 아직 제가 못봤네요;;; 찾으면 있기야 하겠지만은 그만큼 사용빈도가 낮다고 볼수도 있겠습니다.

2012년 2월 19일 오후 8:06, 강동욱 <happens...@gmail.com>님의 말:

--
Google 그룹스 'Korea Spring User Group' 그룹에 가입했으므로 본 메일이 전송되었습니다.
이 그룹에 게시하려면 ks...@googlegroups.com(으)로 이메일을 보내세요.
그룹에서 탈퇴하려면 ksug+uns...@googlegroups.com로 이메일을 보내주세요.
더 많은 옵션을 보려면 http://groups.google.com/group/ksug?hl=ko에서 그룹을 방문하세요.

[강동욱]

그렇군요. 저도 들은 건 아니고 인터넷을 검색하다 어느 글에서 본 거라서 ^^;

그렇다면 지금 하고 있는 업무방식이 가장 현명한 선택이 되겠네요.

답변 감사합니다 ^^

[이상용]

안녕하세요 ^^;;

 

제가 알기로는 속도면에서는 프로시져가 더 빠르다고 알고 있습니다.

최영목님 말씀대로 가독성이나 유지 보수 면에서 개발자들이 관리하기 편하기 때문에

주로 Transaction으로 처리하는 것이지요.

 

기능상이나 프로그램의 흐름상으로는 프로시져의 적극적인 활용이 좋다고 알고 있습니다.

물론 프로시져를 잘 쓰려면 DB에 대한 지식이 필수겠지요.. ^^;;

 

이전 큰 프로젝트를 했을때는 DBA가 직접 해당하는 프로시져를 작성해주셔서

작업한 경험이 있습니다. DBA가 따로 존재하지 않는다면... Transaction 처리가 아무래도 편하겠죠^^;

DBA 보다 잘 만들지는 못하니^^: ㅋㅋ;;

 

좋은 하루 되시기를 바랍니다.

 

2012년 2월 19일 오후 9:33, 강동욱 <happens...@gmail.com>님의 말:

그렇군요. 저도 들은 건 아니고 인터넷을 검색하다 어느 글에서 본 거라서 ^^;

그렇다면 지금 하고 있는 업무방식이 가장 현명한 선택이 되겠네요.

답변 감사합니다 ^^

[karuna maitri]

제가 알기론 ...

프로시져는 DB에 한번 접속으로 여러가지 DB 작업 수행

자바는 DB 작업 수행만 만큼 DB 접속이 발생하여 속도(성능) 차이가 발생한다.라고 알고 있습니다.

요즘에는 여러가지 성능 항샹과 편의상 프로시져 보단 자바로 개발을 많이 합니다만 ...

복잡한 DB 처리나 내부 처리는 아무래도 프로시져가 자바보단 좋지 않을까요?

라는게 저의 생각입니다 ^^;;

2012년 2월 20일 오전 10:41, 이상용 <kr.goo...@gmail.com>님의 말:

[양아름]

음..2000년도 초중반에 프로시져 붐이 불긴 불었었죠...심지어는 조인쿼리까지 프로시져로 만들 정도였으니깐 ..말이죠

 

실제로 그 당시쯤 사이트를 구축한 곳을 보면 간혹 위와같은 경우도 있긴합니다.

 

하지만 서버포퍼먼스의 발달과 회선이라든지 각종 인프라가 뒷바침 되면서 일반적인 업무라면 속도면에서 많은 차이를 보이지 않는것이 사실입니다.

 

또한 트랜잭션 문제 또한 스프링같은 간단하게 트랜잭션을 구성할수 있는 프레임워크들도 많이 나오구요..

 

말대로  배치성 데이터나 빌링작업 아주 데이타적으로 하드한 작업을 제외한다면 프로그램의 업무단위 흐름상 프로시져는 되도록 지향되는 것이 맞다고 생각합니다.

 

요즘은 DBA가 보통 프로젝트 마다 배치되 있고 실제 운영서버와 개발서버가 다른경우가 아주 많은데...(일반적으로 개발자는 운영디비 권한은 없죠 ^^)

 

DBA 가 정말 부지런하게 동기화 작업을 해주지 않는다면 흘러가던 업무로직 끝에 구멍이 하나 뻥뚤려있는거라고나 할까요?

 

또한 동기화를 잘 해주었다 해도 프로시져에 익숙하지 않은 개발자들에겐 고역인건 마찮가지 겠구요

 

보통 DBA가 프로시져 개발을 전담하다 보니 신규로 들어온 개발자는 DBA의 도움없이는 간단한 업무로직 조차 제대로 파악하지 못하는 문제도 발생할수가 있죠.

 

여튼 위와같이 업무 흐름, 유지보수, 가독성등 여러가지 측면에서 본다면 저도 프로시져는 특별한 경우가 아니면 가급적 사용하지 않는 것이 좋다구 봅니다. ㅎ

 

 

 

 

 

2012년 2월 20일 오후 5:09, karuna maitri <pran...@gmail.com>님의 말:

[choiye84 gmail]

오타가 있으시네용~~~ 지향 이 아니라  지양 이겠죵?!^^

나의 iPad에서 보냄

2012. 2. 20. 오후 8:21 양아름 <yabg...@gmail.com> 작성:

음..2000년도 초중반에 프로시져 붐이 불긴 불었었죠...심지어는 조인쿼리까지 프로시져로 만들 정도였으니깐 ..말이죠

 

실제로 그 당시쯤 사이트를 구축한 곳을 보면 간혹 위와같은 경우도 있긴합니다.

 

하지만 서버포퍼먼스의 발달과 회선이라든지 각종 인프라가 뒷바침 되면서 일반적인 업무라면 속도면에서 많은 차이를 보이지 않는것이 사실입니다.

 

또한 트랜잭션 문제 또한 스프링같은 간단하게 트랜잭션을 구성할수 있는 프레임워크들도 많이 나오구요..

 

말대로  배치성 데이터나 빌링작업 아주 데이타적으로 하드한 작업을 제외한다면 프로그램의 업무단위 흐름상 프로시져는 되도록 지향되는 것이 맞다고 생각합니다.

 

요즘은 DBA가 보통 프로젝트 마다 배치되 있고 실제 운영서버와 개발서버가 다른경우가 아주 많은데...(일반적으로 개발자는 운영디비 권한은 없죠 ^^)

 

DBA 가 정말 부지런하게 동기화 작업을 해주지 않는다면 흘러가던 업무로직 끝에 구멍이 하나 뻥뚤려있는거라고나 할

 

[박창준]

저는 많은 프로시져를 봐오지는 못했지만 작은 경험으로 비쳐보면 프로시져릐 장점은 분명히 존재하더군요
하지만 디버깅, 유지보수를 생각하면 불편하더군요
운영중에 프로시져의 어느 부분이 잘못돼었는지 찾기도 힘들고 시간이 지나니 그 프로시져의 정체를 의심한 경우도 발생했습니다


imcjpak-iphone

2012. 2. 19. 오후 8:06 강동욱 <happens...@gmail.com> 작성:

[선영욱]

프로시저는 컴파일 시점에 SQL실행계획을 미리 DB에서 작성해서 질의를 받았을 시점에 실행계획에 따라서 실행만 하므로 성능이 좋다고 알려져 있습니다.

 

같은 내용을 자바로 하려면 프로시저에 있는 SQL만큼 WAS와 DB간에 통신이 발생하고 실행계획을 실시간으로 준비한 후 실행이 된다고 하구요.

 

하지만 프로시저는 함수, 다른 프로시저 들을 포함할 수 있는데요, 그 함수, 프로시저가 깨지면 참조하고 있는 프로시저가 모두 다 깨져버려서 평소에 관심을 가져주지 않으면 오류를 유발할 수 있었습니다.

 

그럼에도 불구하고 정산로직 등의 많은 계산이 필요한 로직이라면 프로시져가 성능상 더 좋은거 같다는 개인적인 생각입니다.

[Jihwan Kim]

성능과 유지보수 효율성. 어느것에 무게를 두느냐 일것 같습니다.
시스템과 상황에 따라 선택하면 되지, 정답은 없다고 봅니다.

일반적으로 닷넷 진영은 프로시져를 좋아하고 자바진영은 그렇지 않더군요. write once, run anywhere 사상에
비추어볼때 프로시져는 지양하게 되는것 아닐까요?

2012년 2월 21일 오전 8:30, 선영욱 <twinmo...@gmail.com>님의 말:

[스쿨쥐]

정답이 없다는 말씀에 동감합니다. ^^ 이유는 프로젝트마다 요구사항(비기능 요구사항포함)이 다르기 때문이죠 ^^

다만 선택의 기준은 많은 분들께서 비슷하게 생각하시는 것 같습니다.

1. 성능이 현재 상황에서 중요한 가치를 지닐 때 : 프로시저
장점 : WAS단에서 로직구현 후 쿼리를 던지는 것보다 성능이 좋음.
단점 : 유지보수 또는 가독성의 저하

2. 성능 이슈가 발생하지 않는 상황 : 그냥 쿼리 날림 ㅡㅅ ㅡ;;;
장점 : 프로시저로 구현하는 것에 비해서 유지보수, 가독성이 좋고, 테스트하기가 용이함.
단점 : 프로시저에 비해서 성능이 떨어짐.

컨텍스트에 따라서 선택하시면 될 것 같습니다. ^^

On 2월21일, 오전9시12분, Jihwan Kim <jhkim...@gmail.com> wrote:
> 성능과 유지보수 효율성. 어느것에 무게를 두느냐 일것 같습니다.
> 시스템과 상황에 따라 선택하면 되지, 정답은 없다고 봅니다.
>
> 일반적으로 닷넷 진영은 프로시져를 좋아하고 자바진영은 그렇지 않더군요. write once, run anywhere 사상에
> 비추어볼때 프로시져는 지양하게 되는것 아닐까요?
>

> 2012년 2월 21일 오전 8:30, 선영욱 <twinmoon2...@gmail.com>님의 말:

[Bee kim]

음..글타래를 읽으면서 드는 생각중에 하나는..

프로시저를 사용해야만 성능 요구사항을 만족할 수 있는 작업이 얼마나 되는가 입니다

대체로 실제 업무에서 성능상 프로시저를 사용해야 한다는 주장은 그런식으로 

작업을 해왔던 분들의 막연한 편견인 경우가 많은 것 같습니다. :-)

주로 유지보수 측면에서 말씀을 드리면...

일단 프로시저를 사용하게 되면 비즈니스로직이 애플리케이션과 데이터베이스에 두 군데 나눠지게 되서 기능의 밀집도에 영향을 끼치게 됩니다. 

문제가 발생했을 때 프로시저와 애플리케이션 로직을 모두 뒤져 봐야하는 경우가 생긴다는 이야기죠.

DBA가 있다면 그나마 다행이지만 없는 경우 문제의 원인을 찾는 일이 난감한 경우가 많이 생깁니다.

또, 데이터베이스에 강한 dependency가 생기게 됩니다. 비즈니스 요구나 성능 요구에 따라서 데이터베이스를 변경하는 일이 발생하게 되면

대략 난감합니다. 프로시저를 분석해서 애플리케이션으로 옮기던가 아니면 또 다른 프로시저를 작성해야 합니다.

또, 프로시저의 경우 버전관리나 권한관리가 쉽지 않습니다. 소스코드는 SVN, GIT같은 버전관리 도구들을 사용할 수 있지만

프로시저의 경우 버전관리를 체계적으로 하기가 무척 힘듭니다. 게다가 변경이 바로 적용되는 구조라 권한관리를 제대로 하지 못할 경우 

작은 실수로 인해 시스템에 치명적인 영향을 미칠 수도 있습니다.

2012년 2월 21일 오전 9:12, Jihwan Kim <jhki...@gmail.com>님의 말:

--
---------------------------------------------
 넥스트리소프트 (주)
 수석컨설턴트, 아키텍트 / 컨설팅사업부 김영진
 서울시 금천구 가산동 371-28
 우림라이온스밸리 A동 405호, 153-786
 Tel : 02-2026-4016   Fax : 02-2026-4020
 Mobile : 010-4012-9409
 E-mail : yj...@nextree.co.kr
 http://www.nextree.co.kr
---------------------------------------------

[딤딤이]

프로시저를 사용해서 대부분의 비지니스 로직을 구현한 프로젝트에 잠시 투입되었다가 고생한 적이 있어 의견 드립니다. 

프로시저 사용하면 상대적으로 비싸고 확장하기 어려운 DBMS에 부하가 몰리게 됩니다.

그래서 성능향상만을 위해서 프로시저를 선택하는 경우 처리해야할 트랜잭션이 늘었을 때 시스템 용량을 확장하기가 매우 어려워 오히려 성능에 안좋은 영향을 끼칠 수도 있을 것 같습니다. 

2012년 2월 21일 화요일에 Bee kim님이 작성:

[무세]

오직 속도를 최우선으로 한다면.. 0.01초라도 속도를 빠르게 해야 한다면..
프로시져가 나을듯 합니다..

하지만 그외적인 측면에서는.. 트랜잭션 방식이 좋을듯 하네요...

[Jin Kim]

대체로 jee 커뮤니티에서는 스토어드 프로시져를 꺼리는 분위기가 많은 듯 합니다.

그렇지만 스토어드 프로시저에는 분명 장점도 있죠.

성능은 두말할 나위가 없고
비즈니스 로직을 스토어드 프로시저에 두는 것은 논란의 여지가 있지만
데이터를 조작하는 로직이라면 스토어드 프로시저에 두어 단계를 추상해서 좀더 나은 설계를 만들 수도 있죠.

voltdb 와 같이 아예 스토어드 프로시져로만 데이터베이스에 접근할 수 있게 하는 극단적인 경우도 있으니
스토어드 프로시져를 꺼릴 필요는 없다 봅니다.

다만 jee로 개발하는 경우 많은 경우가 개발 - 운영이 분리되어 있고 dbms 시스템을 보수적으로 엄격히
운영하기 때문에 스토어드 프로시져를 사용하기엔 커뮤니케이션 문제가 많이 발생하겠죠.

2012년 2월 21일 오전 11:12, 무세 <hsp...@gmail.com>님의 말:

[wonhee]

기술적인 세부내용은 뒤로 미루고요.. 제가 경험했던 내용들을 적어보자면

DBA/빌링팀이 별도로 나누어져 있고 웹개발팀은 거기 손대기도 어렵고 매번 협의하기도 어렵다 이러면 stored procedure입니다.
또한 Spring이나 기타 자바기반 웹서비스만이 아닌 다른 웹서비스, C/C++ 기반 게임서버, 기타등등이 혼재한다면 누군가가 가운데서 미들웨어를 만들고(WebService나 Protocol Buffers등으로) 모든 다른 개발팀이 거기 맞춰서 개발을 진행할 수 있는 여력이 안된다면 가장 편하고 간단한 방법은 stored procedure로 모든 걸 만들고 다른 팀들이 공유하는 것입니다.

운영에 있어서의 부담은 어차피 똑같습니다. 웹기반 미들웨어로 만들어도 외부로 노출되는 인터페이스의 변화가 있는 경우 한날 한시에 모두 정확히 업데이트를 하지 않는 한 장애가 발생하고, Stored procedure기반으로 하는 경우에도 마찬가지입니다.
이상적으로는 동일한 날 변경에 대한 모든 게 적용되어야 하지만, 서비스가 오래 되거나 회사/팀 규모가 너무 커지거나 하면 꼭 한두개 구멍은 생기기 마련입니다. 이 경우 항상 기존 버전과의 호환성을 생각해야 하는데요, 이 경우 대부분 기존걸 안건드리고 새 인터페이스를 만드는 방법을 사용하게 됩니다. 혹은 기존것들도 내부 구현은 변경되더라도 외부로 노출되는 인터페이스는 건드리지 않죠. stored procedure의 경우에는 새 이름의 sp를 작성하거나 기존것과 이름은 같으면서 파라메터가 다른 새 sp를 오버라이드시킵니다. DBA/빌링팀이 꼼꼼하지 않으면 비즈니스 로직에 구멍이 생길 수 있는 것 또한 맞습니다. 하지만 같은 이야기가 웹개발팀에도 적용될 수 있습니다. annotation 등을 하느냐 안하느냐에 따라서 심지어 특정 메소드들은 트랜잭션 메니저의 관리밖에서 돌아가는데 몇달간 혹은 몇년간 아무도 모를 수도 있습니다. 이건 사람에게 달려있는거지 stored procedure를 쓰는데 따른 문제는 아니라고 봅니다.

새로 웹서비스 개발을 하고 웹개발팀 마음대로 할 수 있다 그러면 스프링에 스프링 트랜잭션을 이용하는데 아무런 문제가 없습니다.
하지만 동일한 DB 테이블과 데이트를 공유하는 서로 다른 팀이 운영하는 웹서비스, 모바일 클라이언트(iPhone/Android)와 연동하는 서버, 게임서버 혹은 PC클라이언트, 기타 등등.. 이 있다고 할 때... 이 모든 걸 허용하면서 DB의 트랜잭션을 보장하는 방법은 주요 로직들을 SP로 개발하는 방법이 그나마 제일 낫습니다. SP를 운영하는 DBA나 관련 팀들만 고생하면 되거든요. -_-;; 이 경우 Hibernate를 도입하고 싶어하는 웹개발자들은 상당히 불만이 많아지게 되겠죠. 쓸 이유도 없을 뿐만 아니라 쓴다고 해도 쓰는게 아니니 -_-;;

그리고 프로시져를 사용하게 되면 database 에 강한 의존성이 생길 수 밖에 없는 측면도 분명 사실이긴 합니다만, 그렇게 생각하면 스프링을 쓰는 순간 혹은 웹을 쓰는 순간 그 어플리케이션은 스프링과 웹을 벗어날 수 없습니다. 만약에 다음번에 필요에 의해서 프레임워크를 바꾸어야 한다면 그 순간 모든 트랜잭션 관련된 것들은 새 프레임워크에서 새로 개발되어야 합니다.  필요에 의해서 뭔가를 교체해야 하는 경우 일반적으로 생각해 볼 때 웹프레임워크를 다른걸로 바꿀 가능성이 높을까요 데이터베이스를 바꿀 가능성이 높을까요?

대부분의 상용 서비스들의 경우 예외적인 경우를 제외하고는 어느정도 안정적으로 서비스가 시작된 이후에 데이터베이스를 교체하는 경우는 많지 않습니다.
뭐 예전같으면 infodb나 informix 등으로 갔다가 이런저런 이유로 오라클로 넘어오는 경우가 있습니다만, 오라클로 넘어온 서비스가 다른 dbms로 넘어가는 경우가 실제적으로 몇번이나 있을까요? 성능문제 등을 심각하게 고려해서 만든 서비스라면 개발시부터 충분한 테스트배드를 갖추고 이런저런 실험들을 다 해 본 다음에 해당 DBMS를 선택햇을 것이고, 이 경우 런칭 이후에 문제가 발생한다 하더라도 사실 다른 선택지가 없는 경우가 많습니다.

개인적으로도 stored procedure보다는 하이버네이트든 뭐든 그런걸 써서 하는걸 좋아하는 편이긴 합니다만... 현실은 조금 틀린 경우들이 많더군요. 어느 회사에 입사했는데 이미 sp를 써서 대부분의 주요 업무들을 처리하거 있더라 그리고 웹만 있는게 아니더라 이런 경우는 계속 sp를 쓰는 것 외에는 별다른 방법이 없습니다. 굳이 개선을 할 수 있는 거라면 sp에서 던져주는 에러메세지를 좀 더 자세히 정의하는 정도겠지요.