TIL.56 JPA 플러스 Trouble Shooting

1. FetchType LAZY -> EAGER -> LAZY

처음에 해당 오류를 봤을 때 FetchType이 LAZY이기 때문에
순회 접근에서 해당 정보를 찾기 위해 N+1 문제가 일어난다고 생각했고,
EAGER로 변경했을 때 한 번에 정보들을 모두 조회해 오기 때문에
추가적인 쿼리가 실행되지 않고 N+1 문제가 해결될 것이라는 생각을 했습니다.

하지만 FetchType을 Eager로 설정하게 된다면

불필요한 데이터를 미리 가져와 메모리를 낭비하거나,
관련된 엔티티가 많아질 경우에 쿼리가 너무 복잡해지고

오히려 응답속도도 느려질 수 있다는 생각을 하였고,

다시 LAZY로 변경 후에

 

fetch join과 EntityGraph를 사용하는 방법 중

fetch join 방식은 사용해 봤기 때문에
EntityGraph를 이용해 봤습니다.

EAGER 에서 LAZY로 다시 변경

@EntityGraph 추가

2. JPA 벌크 insert -> JDBC

처음에 JPA로 유저를 생성을 했을 때 컴퓨터 CPU 부족과 인터넷 끊김으로 인해
오류가 발생하여 유저 100만명을 생성하지 못했습니다.

CPU 과부화로 인해 인텔리제이 멈춤

하지만 벌크 insert 같은 경우에는 JPA를 활용하는 경우 보다

JDBC를 이용하면 훨씬 가벼워지기 때문에

JDBC를 선택하였고,
batchSize를 조절하여 cpu의 과부화를 해결하습니다.
뿐만 아니라 생성 자체가 불가능 했던 유저 100만명을 생성할 수 있었습니다.

100만 유저 생성 성공 경축!

3. 결론

이번 프로젝트에서 조회 성능을 더 올리고 싶어서

Docker과 Redis를 따로 공부를 해 두었는데

시간이 부족해서 구현하지 못한 점과

AWS를 사용해 보고 싶었는데 과금 문제에 대한 공지가

추가로 올라오지 않아서 미뤄두었다가 구현하지 못한게 너무 아쉽습니다.

Kotlin 또한 사용하고 싶었지만, 기본 문법 강의도 볼 수 있는 시간이 없었습니다.

 

그래도 아무것도 모르는 제로 베이스에서 시작한 캠프인데

그래도 이번 개인 과제를 통해서 기존에 만들어져 있던 코드를 수정하고,

새로운 기능들을 추가하면서 제 자신이 많이 성장하였다는 것을 체감하였고,

Spring JPA, JDBC, QueryDsl까지 활용할 수 있는

백엔드 개발자가 된 거 같습니다.

 

추후에는 팀 프로젝트나 최종 프로젝트에서 Redis를 꼭 적용해 보고 싶고,

새로운 서비스를 더 나은 방향으로 만들 수 있었으면 좋겠습니다!

 

마지막으로 Kali Linux를 사용해본 경험으로 인해

Windows만 사용해 본 다른 분들에게

Ubuntu라는 운영체제와 GUI만이 아닌 CLI와 Shell Script를 조금이나마

소개하고 도움이 될 수 있어서 너무 좋은 경험이었습니다.

감사합니다!!

나눔 천사 데스페로