주특기 입문/숙련_Day 13

오늘 한 공부 🧐 

• 알고리즘 문제(Java) 1문제 풀이 & 블로그 정리
• Spring 숙련 강의 듣기 (2주차)
• 베이직반 세션 블로그 정리
• Spring 숙련 강의 듣기 (3주차 실습 강의 전까지)
• TIL 블로그 작성

 

오늘 얻은 내용 정리 ✏️ 

강의를 들으면서 이해가 안됐던 부분들 따로 구글링해서 정리했던 내용을 정리해야겠다!

즉시 로딩 (Immediate Loading)

fetch = fetchType.EAGER

Entity를 조회할 때 해당 Entity와 연관된 모든 Entity를 동시에 조회하는 방식이다.

A Entity와 B Entity가 연관되어 있을 때, A를 조회하면 B도 함께 조회된다. 이로 인해 객체 간의 관계를 필요한 시점에 바로 사용할 수 있다.

하지만 조인 등의 복잡한 쿼리가 생성될 수 있고, 불필요한 데이터 로딩으로 인해 성능 문제가 발생할 수도 있다.

즉시 로딩을 선택하는 이유

1. 객체 간의 관계를 활용하기 편리하다.
   • 객체를 조회할 때 연관된 모든 객체가 한 번에 로딩되기 때문에 객체 간의 관계를 편리하게 이용할 수 있다.
   • 모든 연관된 데이터가 이미 로딩되어 있으므로 어떤 객체를 사용할 때 별다른 데이터베이스 조회 없이 객체 그래프를 따라 이동할 수 있다.
2. 복잡한 조회를 단순화한다.
   • 데이터베이스에서 Join을 사용하여 복잡한 연관 관계를 해결할 필요 없이 모든 데이터를 한 번에 가져올 수 있다.

⭐ 지연 로딩 (Lazy Loading)

fetch = fetchType.LAZY

객체를 Proxy로 가져온 후 실제 해당 객체를 사용하는 시점에 초기화한다.
연관된 Entity를 처음에는 조회하지 않고, 실제로 해당 Entity가 필요한 시점에 조회하는 방식이다.
A Entity를 조회해도 B Entity는 초기에 조회되지 않고, B Entity를 실제로 사용할 때 데이터베이스에서 조회된다. 이를 통해 쿼리의 최적화와 성능 향상을 이룰 수 있다.
연관 Entity를 사용하는 과정에서 데이터베이스 쿼리가 추가적으로 발생하게 될 수 있다.
대부분의 JPA 구현체에서 지원되는 기능이다.
Entity 클래스의 연관 관계 필드에 @ManyToOne , @OneToMany , @OneToOne , @ManyToMany 와 같은 Annotation을 사용할 때 fetch 속성을 지정하여 조절할 수 있다.
지연 로딩을 사용하려면 데이터베이스 트랜잭션 내에서 연관된 Entity에 접근해야만 데이터베이스 조회가 일어난다.

지연 로딩을 선택하는 이유

1. 성능을 최적화 할 수 있다.
   • 즉시 로딩은 모든 연관된 데이터를 한 번에 가져오기 때문에, 필요하지 않은 데이터까지 불필요하게 로딩될 수 있고 이는 성능 저하를 야기할 수 있다.
   • 지연 로딩은 필요한 시점에만 데이터를 로딩하기 때문에 성능을 최적화 할 수 있다.
2. 데이터 접근이 최적화된다.
   • 사용자가 실제로 해당 데이터를 사용할 때만 로딩하기 때문에 데이터베이스 접근이 최적화된다.
   • 따라서 시스템 전체적으로 데이터 로딩에 대한 부하가 분산될 수 있다.
3. 순환 참조를 방지할 수 있다.
   • 객체 간의 연관 관계에서 순환 참조가 발생할 확률이 줄어든다.
   • 객체를 조회할 때 실제로 필요한 데이터만 로딩되므로 무한한 순환 참조를 방지할 수 있다.
4. 메모리 사용을 최적화 할 수 있다.
   • 즉시 로딩은 연관된 모든 데이터를 로딩하기 때문에 메모리를 많이 사용할 수 있다.
   • 지연 로딩은 필요한 데이터만 로딩하기 때문에 메모리 사용을 최적화 할 수 있다.

실무에서는 모든 연관 관계에 지연 로딩을 사용해야 한다!
즉시 로딩을 적용하게 되면 예상하지 못한 SQL이 발생할 수 있다.

1차 캐시

영속성 컨텍스트 내부에는 있는 Entity를 보관하는 저장소를 1차 캐시라고 한다.
일반적으로 트랜잭션을 시작하고 종료할 때까지만 1차 캐시가 유효하다.
1차 캐시는 Key-Value 형태의 구조를 가진다.

• Key : DB의 기본키
• Value : Entity

EntityManger를 통해 find 명령으로 DB를 조회했을 때, DB를 먼저 찾는 것이 아니라 영속성 컨텍스트의 1차 캐시를 먼저 조회한다.
find 시에 입력 받은 id 값이 1차 캐시에 존재하면 그 값을 찾아 return해준다.

persist를 한 다음, find를 수행하는 코드가 있다면 find 수행 시 DB를 조회하지 않고 1차 캐시의 값을 가져올 것이기 때문에 select 쿼리는 사용되지 않을 것이다.
실제 결과도 insert 쿼리만 수행하는 것을 확인할 수 있다.

1차 캐시에 값이 없다면 어떻게 작동할까?!

1. find 시, 1차 캐시를 조회한다.
2. 1차 캐시에 입력 받은 id를 가진 데이터가 존재하지 않으면 DB를 조회한다.
3. DB에서 가져온 데이터를 1차 캐시에 저장한다.
4. 1차 캐시에 저장한 값을 return한다.

1차 캐시의 한계

사실 1차 캐시는 효율성을 크게 제공해주지 못한다..
요청마다 생성되는 영속성 컨텍스트는 요청이 끝나고 트랜잭션이 종료될 때 함께 사라지기 때문에 1차 캐시는 큰 도움이 안되는 경우가 많다.
물론 비즈니스 로직이 굉장히 복잡한 경우엔 쿼리가 줄어들긴 하지만, 1차 캐시의 성능보다 매커니즘에서 얻는 이점이 더 크다.

2차 캐시

애플리케이션에서 공유하는 캐시를 JPA는 공유 캐시(Shared Cache)라고 하는데 일반적으로 2차 캐시(Second Level Cache, L2 Cache) 라고 부른다.

2차 캐시는 애플리케이션 범위의 캐시이므로 데이터베이스 조회가 1차 캐시만 사용할 때 보다 획기적으로 줄어든다.
1차 캐시에서 Entity를 찾아보고 없으면 2차 캐시에서 Entity를 찾는다.
찾는 Entity가 존재하면 2차 캐시에서 반환하고 존재하지 않으면 DB를 조회해서 반환한다.
이때 2차 캐시는 동시성을 극대화하기 위해 직접 반환하지 않고 복사본을 만들어 반환한다.
여기서 복사본을 반환하는 이유는 객체를 그대로 반환하면 여러 곳에서 같은 객체를 동시에 수정하는 동시성 문제가 발생할 수 있다.

 

오늘 하루 정리 ✏️

오늘은 오전에 알고리즘 문제 풀고 개인 과제 발제를 들었다.
Spring 입문 주차의 과제에서 Develop을 하는 것이었는데 생각보다 쉬워보이면서도 내가 할 수 있을까..? 하는 생각이 들었다.

오후에는 계속해서 Spring 숙련 강의를 들었다!
입문 강의보다는 이해가 잘되서 진도가 쭉쭉 나갔는데 그 중에서도 이해가 안되는 부분들은 따로 메모해두고 저녁 시간 이후에 구글링을 하면서 이해했다!

강의 듣는 중간에 집중력이 끊겨서 베이직반 세션을 블로그에 정리했다! 블로그에 정리하면서 다시 한번 복습하니까 내용이 더 잘 기억되는 느낌이었다! 어제 튜터님의 설명이 귀에 쏙쏙 들어와서 그런가 😃😃😃

오늘 하루도 알차게 공부하면서 잘 보낸 것 같다. 오늘 하루종일 열심히 강의 들으면서 이해했으니까 푹 쉬고 내일도 열심히 공부해야겠다!!!

내일 하루도 힘내보자!!

 

내일 계획 ⏰

• 알고리즘 문제(Java) 1문제 풀이 & 블로그 정리
• Spring 숙련 강의 듣기 (3주차)
• Spring 숙련 강의 내용 전체적으로 복습
• 과제 시작해보기(?)
• TIL 블로그 작성

+ 추가로 계획이 더 생길 수도 있슴다~_~