반응형

Stored Procedure ....SP라고도 무르는 것 같은데......

Anyway...장단점에 대해서 정리해 본다.


Stored Procedure 는 Oracle DBA로 재직하면서 끊임없이 나와 마주했던 친구다.

내가 처음부터 끝까지 다 작성한 것은 많지 않지만..문제 발생 시 개발자와 같이 확인하고..Invaild로 상태가 바뀌었는지 체크하고

바뀌었으면 왜 바꼈는지...누가 해당 부분을 수정했는지 확인했다.


그리고 때로는 튜닝 요청관련해서 몇백줄 몇천줄 나의 능력을 뛰어넘는 놈을 이겨볼 꺼라고 아둥바둥 거렸다.


각설하고 MySQL에서는 Stored Procedure 라고 명명 한다.


장점


- DB 보안 향상

  -> 자체적인 보안 설정 기능을 가지고 있으며, Stored program 단위로 실행 권한을 부여할 수 있다.

  -> 세밀한 권한 제어가 가능

  -> SQL 인젝션과 같은 기본적인 보안 사고는 피할 수 있다.

  -> SQL 의 문법적인 취약점을 이용한 해킹이 어렵다


- 기능의 추상화

  ex) 여러 테이블에 걸쳐 유일한 일련번호를 발급하되, 일련번호에 자체적인 헤더 값과 시간 정보를 덧붙여서 생성

  -> 이러한 요구사항을 해결하기 위해서는 단순 Table 시퀀스(auto increment)를 사용하지 못하는데 Stored procedure 이용하면 해결가능


- 네트워크 소요 시간 절감

  -> 하나하나의 쿼리가 아주 가볍고 빠르게 처리될 수 있다면 네트워크를 경유하는 데 걸리는 시간이 문제가 될 수 있음

   (0.01만에 완료되는 쿼리가 0.1초의 네트워크 시간과  동일한 쿼리가 다량의 건수로 진행되는 경우 문제 소지)


- 절차적 기능 구현

  -> SQL 문장에 IF / While 과 같은 제어문장 사용 가능

    ( 어플리케이션 소스코드를 줄여줄 수 있음)


- 개발 업무의 구분

  -> 스토어드 프로그램을 만들어 API 처럼 제공하여 업무 구분


단점


- 낮은 처리 성능

  -> 다른 DBMS에 비해 Stored Procedure 프로그램은 성능이나 최적화가 부족하여 수행 능력이 떨어짐(오라클 pl/sql보다 2배 떨어짐)

  -> 문자열이나 숫자 연산을 위해 사용하기에는 나쁜 선택

  -> 하지만 한 번에 많은 쿼리를 실행해야 할 때 효율적임


- Application 코드의 조각화

 ??????이해가 되지 않기에 패스..


출처 : 개발자와 DBA를 위한 MySQL 서적


- 나의 생각 : 나는 Stored procedure 를 많이 만들지 않았지만 분명 여러가지로 유용한 부분이다.

Oracle로 비유하자면 많은 쿼리들이 Library cache에 등록이 되고 공유가 된다. 이 때 대,소문자 구분 및 바인드변수 미사용 등으로 동일한 쿼리이지만 전혀 다른 쿼리로 인식하여 실행계획이 공유되지 않는 상황이 발생된다. 이말은 즉슨, 동일한 쿼리로 인식하지 않기에 매번 하드파싱이 일어나 조금이라도 부하를 주게 된다. MySQL로 돌아와서 비슷한 것이라고 생각된다. MySQL에서 Stored procedure를 이용하게 되면 많이 사용되는 쿼리일 수록 부하는 줄게 될 것이고 성능적으로 향상될 것이다.

물론, 개발자들이 쿼리 규칙을 잘 지킨다면 걱정없겠지만...그게 아니라면 SP를 사용하는 것이 좋다고 생각든다.


몇주전에 어느 담당자가 SP는 MySQL 에 부하가 되기 때문에 사용을 지양 한다고 했었다.

나는 그 말에 동의 하지 않는다....

SP를 잘 사용한다면 많은 이득을 볼 수 있을 것이라고....


어디까지나 나의 생각일 뿐이다. 허접한...ㅠ

반응형

+ Recent posts