내가 이번 성능 개선 프로젝트에서 가장 중심적으로 개선 중인 사항은 트리거와 프로시저인데, 어떤 한 기능을 트리거로 구현하느냐 프로시저로 구현하느냐이다.
배송 주문이 생성되는 과정을 예로 들면,
주문 상태가 '상품 준비중' 으로 변경됨 -> 주문에 기사가 할당되며 배송 주문 생성 -> 고객과 기사 채팅 채널 생성 -> 배송보험 가입
다음과 같이 프로세스가 진행된다. 처음에는 이 과정을 주문 테이블에 트리거를 걸어서 주문 상태가 '상품 준비 중'으로 변경되었을 때 순차적으로 실행되도록 쿼리를 작성했다.
하지만 트리거에 대해 알아보면서 '복잡한 쿼리는 트리거가 아닌 프로시저로 실행시키는게 좋다.'는 정보를 찾을 수 있었다.
그 이유에 대해서 단순히 '복잡한 트리거는 트랜잭션 관리도 어려울뿐더러 안정성을 해친다.' 정도로만 이해하게 되었고, 트리거를 프로시저로 바꾸는 작업을 진행했다.
하지만 프로시저로 바꾼 후 실행 속도는 현저히 느려졌고, 복잡한 쿼리의 일부를 트리거로 바꾸면서 실행속도를 줄이기 시작했다. 그렇게 쿼리를 바꾸던 도중 트리거를 프로시저로 바꿔야 하는 이유가 뭘까에 대해 고민하기 시작했고, 트리거는 복잡한 쿼리를 안 쓰는 게 좋다고 했는데 복잡한 쿼리의 기준이 뭘까를 생각하게 되었다.
그래서 최종적으로 든 의문이 트리거와 프로시저는 언제 써야할까이다.
얻어낸 해답은 트리거와 프로시저의 실행되는 시점에서의 차이에 있는데
트리거의 경우 실행되는 시점을 내가 정할 수 없고, 프로시저는 정할 수 있다는 것이다. 그리고 이 차이점은 서버의 리소스와 연관이 있다.
많은 요청으로 인해 서버의 부하가 심한 경우에도 트리거는 정해놓은 조건이 만족하는 순간 무조건 실행된다.
하지만 프로시저의 경우 서버의 리소스를 확인하여 실행할지 말지 결정할 수 있다. 즉, 서버의 리스크 관리에 있어 트리거보다 프로시저가 훨씬 유리하다는 것이다.
이것이 내가 궁금했던 '복잡한 쿼리는 트리거가 아닌 프로시저로 실행시키는 게 좋다.'의 이유 중 하나가 될 수 있을 것이다. 결론적으로 '제어'라는 키워드가 트리거와 프로시저를 구분 짓는 핵심적인 요소인 것이다.