복잡한 쿼리를 보내더라도 디비에서 처리 vs 서버에서 처리

 

친구의 질문 덕분에 새로운 고민거리가 생겼다. 

복잡한 쿼리문을 만들더라도 디비에서 최대한 데이터를 가공해서 가져오는 게 좋을까,

아니면 간단한 쿼리문을 날려서(필요하다면 여러개를) 서버에서 데이터를 처리하는게 좋을까?

 

구글링을 해보니 많은 의견들이 있었는데, 재미있는 내용이 많아서 정리해보려고 한다.

 

 

자료1: 복잡한 비즈니스 로직은 서비스 레이어에 넣자

https://okky.kr/questions/676406

OKKY - 쿼리에서 연산해야할까요 자바에서 연산해야할까요

 

 

해당 댓글을 참고했다. 

 

입장: 복잡한 비즈니스 로직은 디비보단 서비스레이어에서 하자! 

• 프로시저에 비즈니스 로직을 넣지말자
• 이유
  • 관리/테스트/확장이 쉽다
  • 서비스 레이어에 비즈니스 로직이 있다면 조금 더 유연한 서비스를 만들 수 있음  - 디비가 바뀌어도 유연하게!
  • n티어 아키텍처를 이용하는 이유 - 비즈니스 로직이 애플리케이션의 핵심자산

 

 

자료2: 다양한 의견들

https://stackoverflow.com/questions/7510092/what-are-the-pros-and-cons-of-performing-calculations-in-sql-vs-in-your-applica

What are the pros and cons of performing calculations in sql vs. in your application

 

• 계산의 복잡성, 데이터 량, 편의성을 고려해서 정해야함
• 복잡한 크런칭은 앱서버에서 하는 게 선호됨 (앱서버 scale out이 디비를 scales up하는 것보다 선호되는듯)
• 데이터를 가져올 때는 열과 행을 최소화하는 게 유리하다
  • 서버에서 쿼리를 잘 보내면 많은 네트워크 대역폭을 절약할 수 있음

 

 

• SQL 서버에서 필요하지 않은 데이터 행을 가져오지 않는 게 좋다.
• 집계작업은 SQL에서 하는 게 좋을 가능성이 높음

 

• 금광석을 운반하는 예시를 들어주셨다
• 앱과 서버 사이 네트워크 비용은 상대적으로 비용이 많이 듦 -> 줄이는 게 좋다
  • 필요한 경우에는 서버측 프로시저나 정교한 쿼리문을 사용 
• 상황에 따라 적절하게 하는 게 좋다(답글)
  • but the details of the case must generally be taken into account when making that kind of determination

 

• 일반적으로 row level 계산은 큰 차이가 없음
• 차이점 
  • SUM(), AVG(), MIN(), MAX() 와 같은 집계함수는 데이터베이스 엔진이 java 구현보다 훨씬 빠름
  • DB에서 필터링하는 게 필요없는 데이터를 가져오는 것보다 낫다

 

• SQL은 성능이 과소평가됨 -> 많은 non-strictly set-oriented 계산이 쉽고 우아하게 수행가능
• 따라야하는 법칙
  • 디비와 애플리케이션 간 전송되는 데이터량을 slim하게 유지
  • 디비에 의해 디스크에서 로드된 데이터 량을 slim하게 유지
  • 복잡하고 동시적인 계산으로 데이터베이스를 CPU limit까지 밀어붙이지 마세요
    • 데이터를 애플리케이션 메모리로 가져와서 계산하는 걸 선호한다고 함

 

 

 

자료3: 프로시저에 업무로직을 넣지말자

https://sorrymommy.tistory.com/36

프로시저에 업무로직(비지니스로직)을 넣으면 안되는 이유

• 자신의 경험을 녹여서 글을 써주셨는데 정말 좋은 글인 것 같다.
• 비즈니스 로직을 프로시저에 넣으면 속도는 빠르다
• 하지만 단점이 너무많음
  • 긴 로직의 경우 소스코드 이해가 힘듦
  • 테스트 힘듦
  • 소스코드 관리가 되지 않음
  • 무결성 보장이 제한적이다
  • 성능향상에 매우 많은 비용과 노력이 든다 - 분산처리가 매우 힘듦★ ★ ★

 

(작년에 한 프로젝트에서 트리만큼 깊어질 수 있는 카테고리를 구현할 때 프로시저를 사용한 기억이 있다. 서비스레이어에서는 프로시저를 호출만 하고, 가져온 데이터를 그대로 json으로 변경해서 클라이언트에게 보내줬다. 나름대로 주석도 달면서 다른 백엔드 팀원이 이해하기 쉽도록 작성하려고 했지만 이해가 힘들다는 의견을 받은 기억이 있다. 프로시저에 익숙하지 않아서 그런 줄 알았는데, 현업에서도 기피하나보다)

 

 

 

자료4: 디비에서 할 수 있는 집계성 쿼리는 디비에서 처리하는게 좋음

https://www.inflearn.com/questions/75443/db%EC%97%90-%EB%82%A0%EB%A6%AC%EB%8A%94-%EC%BF%BC%EB%A6%AC%EB%8A%94-%EC%B5%9C%EB%8C%80%ED%95%9C-%EA%B0%84%EB%8B%A8%ED%95%98%EA%B2%8C-%ED%95%98%EB%9D%BC%EB%8A%94-%EC%9D%98%EB%AF%B8

db에 날리는 쿼리는 최대한 간단하게 하라는 의미 - 인프런

 

• 최대한 DB의 기능을 사용하기
• 집계성 쿼리는 디비에서 처리하는 게 좋고, 최대한 필요한 데이터만 가져오는 게 좋다

 

 

 

 

 

배운 내용

• 디비서버와 앱 서버간의 네트워크 비용은 상당히 크다
• 디비의 집계함수는 상당히 빠르다
• 비즈니스 로직은 웬만하면 서비스 레이어에 넣자
  • 프로시저에 다 때려넣는 짓은 하지말자

 

 

그동안 이 부분을 생각하지 않고 개발했는데 새로운 시각이 생긴 것 같다.

데이터베이스의 집계함수와 윈도우함수에 대해 좀 더 깊게 공부해보고싶다.