stored procedure를 백엔드 실무에서 쓰기에 조심스러운 이유

비지니스 로직은 어플서버단에서 다루는게 더 좋다
( procedure로 DB쪽에서 다루는거보다 )

 

3-tier architecture

ex) 당근마켓의 비지니스 로직	ex) 당근마켓의 데이터
회원가입/ 탈퇴 상품 리스트업 알고리즘 상품정보 업로드 기능 상품 검색 기능 메시지 기능	회원정보 상품정보 판매/구매내역 지역 정보

 

stored procedure
주된 사용목적 : 비지니스 로직 구현

 

stored procedure의 장점

비지니스 로직이 프로시저로 관리되면
위와같은 상황에서

번거롭게 각자 구현을 하거나 수정을 할 필요 없다

 

어플리케이션 서버, db서버 ( 서로 다른서버임 )

비지니스 로직이 어플리케이션 서버에 있을경우
sql문을 수행 할때마다 네트워크 트래픽 발생

 

stored procedure 를 쓰기 조심스러운 이유

번거러운 측면들이 생김

 

비지니스 로직이 프로시저로 관리되면

트래픽이 늘어날경우 cpu, 메모리 사용량이 DB는 급격히 증가하고

cpu혹은 메모리 부하를 쉽게 분산시킬수 없음

( 어플리케이션 서버투입은 DB서버를 추가하는것 보다 간단 )

 

수정한 비지니스 로직에 버그가 있을경우
stored procedure를 사용하게 되면 모든 서버가 영향을 받지만
어플서버단에서 로직을 구현하면 버그의 영향을 최소화 할수 있음( 어플서버들을 순차적으로 실행 가능 )

 

쓰레드 풀 or 논 블락 아이오
사용해서
동시에 DB서버로 요청

 

케시(레디스)를 사용해서 응답속도 향상
어플서버와 DB사이에 케시를 두는것은 많이 사용되는 패턴임

getFromCache(id) : id 에 대한 point가 cache에 있는지 확인

id에 대한 point가 cache에 있는 동안에는
응답속도향상 + db부하도 줄임