이전에 한가지 질문에 봉착했다.
"SQL에서 Join을 안쓴다면, Join을 안 만들었겠지. 근데 Join을 만들었다는건 쓰라는거잖아?"
내가 Join을 잘 사용하지 않고, 데이터 처리를 하는걸 보고 들은 이야기이다. 물론 필요해서 만들었다가, 생각보다 효율이 안나오는 사례도 있기 때문에 저말이 정답은 아니라고 생각하지만, Join 잘 활용하는 것도 능력이긴 하니까.
그렇다면 Join을 쓰는 사례와 안 쓰는 사례에 대해서 고민을 해보았고, 그 과정에서 Lazy Loading 을 접했다.
우리는 NoticeContent Table 과 NoticeComment Table 을 갖고 있으며, 각 Notice list를 반환시키는 함수를 만든다고 가정하자.
content_list = NoticeContent().get_content_list()
result = []
for content in content_list:
comment_list = Comment().get_comment_list(content)
result.append(comment_list)
return result
위 코드에서는 SELECT 가 2번 일어난다. Content 테이블에서 컨텐츠 리스트를 DB에서 가져오는 함수(get_content_list)에서 1번 + Comment 테이블에서 코멘트 리스트를 가져오는 함수(get_comment_list) 1번 이다.
Lazy loading은 필요한 시점에 데이터를 로딩하는 방식이다. 예를 들어, 게시판의 글 목록을 조회할 때, 해당 글의 작성자 정보를 로딩하지 않고, 글 목록만 먼저 조회한 후, 사용자가 글을 클릭하여 상세 페이지로 이동할 때 작성자 정보를 로딩한다. 이렇게 필요한 데이터만 로딩하므로, 불필요한 데이터를 로딩하지 않아 성능상 이점이 있다.
Eager loading은 객체를 조회할 때, 연관된 모든 객체를 함께 로딩하는 방식이다. 예를 들어, 게시판의 글을 조회할 때, 해당 글의 작성자 정보를 함께 로딩한다.
이렇게 연관된 모든 데이터를 로딩하므로, 한 번에 모든 데이터를 처리할 수 있어 편리하지만, 모든 데이터를 로딩하므로, 불필요한 데이터까지 로딩하게 되어 성능상 이점이 없을 수 있다.
Eager Loading 이면 코드가 다음과 같아진다.
result = Notice().get_notice_detail()
return result
두 테이블 Join 시켜 처리 -> Eager Loading
한 테이블 Select 한 데이터에서 뽑아서, 다른 테이블 Select에 패싱 -> Lady Loading
Eager Loading 으로 하는게 쿼리를 적게 커밋하므로 효율적으로 보일 수 있으나, 실제로는 설계된 테이블에 대한 이해도가 필요하고, 시스템이 복잡해짐에 따라 유지보수 측면에서 어려워질 수 있다.
따라서 기본적으로 Lazy Loading 으로 짜고, 성능에 이슈가 생기는 경우 Eager Loading 처리 하는게 낫다고 한다.
물론 기본적으로 프로그래머라면 좋은 코드와 효율성을 목표로 하는 것이 맞다.
하지만 실제 일이라는 것에 리소스는 한정이 되어 있다.
가령 잘 쓰이지 않는 내부 어드민용 API에 캐시 관련 처리를 하는 것은 비즈니스적으로
오버헤드일 가능성이 있다. 그 시간에 사용자 친화적인 개발을 하는 것이 더 합리적일 수 있으니깐.
결국 무엇이든 부딪혀야 답이 나온다는 점!
'컴퓨터 공학' 카테고리의 다른 글
👉 [Infra] Nginx 기반 무중단 배포를 직접 만들어 보자. (0) | 2022.04.25 |
---|---|
👉 [JAVA] JPA 및 관련 정의 (0) | 2022.02.21 |
👉 [CS] CS 지식은 필요한가? (0) | 2021.07.18 |
👉 [CS] Layered Pattern 레이어드 패턴 구현 (0) | 2021.07.11 |
👉 [CS] Docker 기반 Microservice 구현 (0) | 2021.07.06 |