너무 성능이 안나와서 튜닝을 하러 갈 때가 있는데요, 대부분 아래의 문제들에서 다 걸립니다.
그래서 해당 문제들을 만났을 때 어떻게 잘 해결할 수 있는지 알아보도록 하겠습니다.
먼저 조회용 샘플 데이터를 입력하겠습니다.
왜냐면 사실 등록과 수정은 성능 문제가 거의 발생하지 않습니다. 그냥 데이터 한 건 넣는 작업이기 때문이죠.
주로 문제가 되는 것은 조회입니다.
시스템마다 다르겠지만 장애의 90% 이상은 조회 API 에서 나옵니다. 사람들이 조회를 더 많이하기 때문이죠.
그래서 조회에 대한 내용을 다루려고 합니다.
조회할 때 API 의 성능을 어떻게 최적화하고, 어떤 식으로 설계하는게 좋을지 알아볼겁니다.
근데 서버를 껐다 켰다 할 때마다 데이터가 초기화 되면 좀 짜증나니까 조회용 샘플 데이터를 먼저 입력을 하겠습니다.
지연 로딩과 조회 성능 최적화에 대해 알아보겠습니다.
JPA 를 사용하면서 소위 말하는 N + 1 문제를 경험하게 됩니다.
쿼리 한개, 두개로 해결될 게 막 수십개가 나가는 경우가 생기게 됩니다.
고객이 API 를 많이 요청하는 상황에서 쿼리가 많이 나가면 성능이 많이 저하되겠죠.
그래서 이런 문제를 어떻게 최적화 하는지 단계적으로 설명을 하겠습니다.
컬렉션 조회 최적화에 대해 알아보겠습니다.
일대일 관계나 다대일 관계처럼 조인을 했는데 데이터가 늘어나지 않는 경우에는 성능에 이슈가 없습니다. 막 조인을 해도 됩니다.
그런데 일대다 관계에서 조인인 경우는 데이터가 뻥튀기가 돼서 늘어버립니다.
이런 경우는 성능 최적화 하기가 만만치가 않습니다. 그때 JPA 를 사용해서 어떻게 최적화를 할 수 있는지 알아보겠습니다.
paging 한계 돌파에 대해서 알아보겠습니다.
페이징 쿼리는 일대다 조인을 하는 경우 데이터가 뻥튀기 돼서 페이징하기가 어렵습니다.
예를 들어, 회원과 주문이 있다고 합시다.
회원 데이터를 기준으로 페이징을 하고 싶은데 주문과 조인을 해버리면 어떻게 될까요?
회원이 한 개고 주문이 두 개면 데이터가 두 배로 증가되는 거죠.
이게 페이징 하는 게 되게 어렵습니다.
그래서 이런 한계에 어떻게 JPA에서 성능 최적화를 해야하는지 알아보겠습니다.
OSIV 와 성능 최적화에 대해서 알아보겠습니다.
OSIV 는 open session in view 입니다.
이것을 사용하게 되면 지연 로딩에서 되게 편하게 되는데 사용 안하게 되면 레이지 로딩 익셉션을 되게 자주 만나게 됩니다.
그래서 어느 상황에는 켜야 되고 어느 상황에는 꺼야 되는지 심도있게 설명하면서 케이스로 정리를 하겠습니다.
그리고 실무에서는 어떻게 하는 게 좋은지도 설명하겠습니다.