JS와 SQL 그리고 JAVA.. 데이터 가공과 비즈니스 로직은 어디에

주로 일&공부를 하며 디비에서 데이터 끌어다 화면에다가 보여주는 기능 패턴을 제일 많이 개발하는 것 같다.

이때 사용자에게 화면을 통해 보여주기 위해서는 데이터 가공이 필수적이다. 매번 이런 작업을 하며 궁금했던거..

 

데이터 가공은 어디에서 이뤄져야 가장 성능이 좋을까? 혹은 효율적일까?

 

데이터가 적을때야 크게 성능에 차이가 없다지만 데이터는 계속 쌓이는거고 어느 순간 성능에서 차이가 나는 순간이 생길텐데 나는 가장 성능 좋고 효율적인 개발을 하고싶단말야😱

항상 궁금했던건데 오늘 맘먹고 찾아서 정리해볼테다

 

[sql 쿼리 속도 vs Java 코드 속도 어느게 더 빠른가요?] https://okky.kr/articles/1056243

OKKY - All That Developer

• DB는 스토리지, 데이터 저장에 특화된 것이다.
• 어플리케이션의 비즈니스 요건과 SQL 형태에 따라 다르다.
  어플리케이션이 DB 중심이 아니라 객체 중심이라면 서비스 특성에 따라 적절히 분리해서 매핑할 수 있다.
• 하나의 SQL을 수행시키는 것이 다수의 SQL을 수행시키는 것보다 더 효율적이다.
• 최적화 중 가장 우선이 DBMS Call 자체를 줄이는 것

 

[비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유] https://www.itworld.co.kr/news/208352

비즈니스 로직을 DB가 아닌 앱에 넣어야 하는 이유

• 데이터베이스에서 어플리케이션 로직을 완전히 배제해야하는 것은 아님
• 데이터베이스에서의 비즈니스 로직을 최소화하고 최대한 어플리케이션 코드에서 그 로직을 다뤄야한다.
  다음과 같은 쿼리 지향 > SELECT POWER(SQRT(COL1) * (COL2), 5) FROM ...
  대신 다음과 같게 > SELECT COL1, COL2 FROM ...
  그 다음 반환된 결과로 어플리케이션에서 POWER(SQRT(...)) 작업 수행
• 이유는 일반적으로 어플리케이션 서버 리소스가 데이터베이스 서버 리소스보다 확장하기 훨씬 쉽기 때문 (!!!)
  계산을 수행할 때 데이터베이스 리소스가 아닌 좀 더 풍부한 어플리케이션의 리소스를 활용하게 한다. 

 

[웹어플리케이션 속도,비용 자바 vs 쿼리] https://okky.kr/articles/410805

OKKY - All That Developer

• 이건 정답이 없다..
• 쿼리로 처리하는게 속도는 더 빠를지도 모르지만 결국 화면과 클라이언트, 서버 상황까지 고려했을 때 쿼리가 정답은 아니다.

 

[SQL where 문 vs Java stream filter 성능차이에 관한 질문입니다] https://www.inflearn.com/questions/184494

SQL where 문 vs Java stream filter 성능차이에 관한 질문입니다 - 인프런 | 질문 & 답변

• 데이터 양에 따라 다르다.
• where 절의 경우 DB에서 최대한 필터링하고 가져오는 것이 좋다. 특히 대용량일수록!

 

[DataBase의 책임 - DB는 어디까지 해줘야 하는가] https://jaehoney.tistory.com/183

Database의 책임 - DB는 어디까지 해줘야 하는가? (+ 데이터 가공, 비즈니스 로직, 계산 등)

• 이전부터 비즈니스 로직이 어디에 있어야 하는지는 큰 관심사였다고 한다.
• 3계층 구조(Three-Tier Architecture)
  
  • 프레젠테이션 계층
    일반 사용자가 어플리케이션과 상호작용하는 사용자 인터페이스 및 통신 계층
    정보를 표시하고 사용자로부터 정보를 수집한다.
    최상위 레벨 계층인 웹 브라우저, 데스크탑 어플리케이션, GUI부터 웹 프리젠테이션 계층은 일반적으로 HTML, CSS, JS로 개발됨
  • 어플리케이션 계층
    논리 계층 또는 중간 계층이라고도하며 어플리케이션의 핵심
    프리젠테이션에서 수집된 정보가 처리되고 비즈니스 로직을 사용해 데이터를 처리한다.
  • 데이터 계층
    어플리케이션이 처리하는 정보가 저장 및 관리되는 곳
    관계형 데이터베이스 시스템(RDBMS) 또는 NoSQL 등이 있다.
• 데이터베이스는 행위나 동작의 책임을 분리해서 데이터를 정리하고 저장하는 용도로 사용하고
• 행위나 동작은 다른 Layer로 책임을 인가해서 어플리케이션, DB, 클라이언트가 각각 독립적으로 존재하는 것이 유지보수에 좋다.
• 즉, 데이터베이스는 데이터를 필터링, 그룹핑, 솔팅까지 해서 넘겨주고 / 어플리케이션단에서 비즈니스 로직을 태우고 / 화면단에서 데이터를 가공해 표시하는 것이
  설계와 유지보수 관점에서 바람직하다. 

[3계층 아키텍처] https://www.ibm.com/kr-ko/cloud/learn/three-tier-architecture

 

 

대충 혼자 결론을 짓자면

• DB가 스토리지에 최적화된 시스템인만큼 필터링의 경우 DB에서 최대한 처리하여 최소한의 데이터를 가져오자.
• 리소스 측면에서 서버 리소스가 활용도와 확장 가능성이 더 크다. 서버 리소스를 활용하도록 하자.
• 3계층 구조에 의해 DB는 데이터를 필터링해 어플리케이션에 넘겨주고 어플리케이션에서는 비즈니스 로직을, 화면에서는 화면만을 위한 가공을 이뤄내는 것이 좋다.

 

---

이 외에도 추가적으로 궁금했던거 하나 더

Model에 데이터를 담아 JSTL로 화면처리하는게 더 좋을까 아님 ajax로 데이터를 가져와 js, jquery 사용해 화면에 뿌리는게 날까

 

JSP에서 동적태그 생성시 JSTL VS JS 사용에 관해서 https://okky.kr/articles/738972

OKKY - All That Developer

가장 와닿는 말은 렌더링해야하는 데이터가 많을때, JSTL에서는 렌더링 후 화면이 보여지기 때문에 기다리는 사용자가 봤을 때 보기 좋지 않다는 점

하지만 JS의 경우 화면 먼저 로딩 후 렌더링을 위한 로딩 이미지 진행 후 렌더링 완료 후 사용자에게 보여줄 수 있다는 점 바로 비동기적 특성!

따라서 답변 마지막처럼 변하지 않는 화면 요소는 JSTL에서 처리하고 동적인 부분은 ajax로 처리하는게 좋은 방법인 것 같다.