이 글은 자바 표준 ORM JPA 프로그래밍 책을 보고 정리한 글입니다. 2차 캐시의 필요성 네트워크를 통해 DB에 접근하는 시간 비용은 어플리케이션의 내부 메모리에 접근하는 비용에 비해 수만 ~ 수십만배 이상 비싸다. 따라서 필요한 데이터를 매번 DB에서 조회하는 것보다는 어플리케이션 메모리에 캐시 후, DB 접근 횟수를 줄이면 어플리케이션의 성능을 획기적으로 개선할 수 있다고 한다. JPA의 영속성 컨텍스트 영속성 컨텍스트 내부에는 엔티티를 보관하는 1차 캐시가 있다. 그렇지만 이 1차 캐시는 영속성 컨텍스트가 존재하는 동안에만 캐시로 사용할 수 있다. 스프링의 기본적인 영속성 컨텍스트 전략은 트랜잭션이 시작할 때 영속성 컨텍스트를 만들고, 트랜잭션이 종료되면서 영속성 컨텍스트를 종료한다. OSIV를..
이 게시글은 자바 표준 ORM JPA를 공부하고 개인적으로 정리한 글입니다 트랜잭션의 성질 트랜잭션은 ACID 성질을 만족해야한다. 트랜잭션의 ACID는 아래를 이야기한다. Atomic(원자성) 트랜잭션 내의 동작은 같이 성공하거나, 같이 실패해야한다. Consistency (일관성) 트랜잭션이 성공적으로 완료되면 일관적인 DB상태를 유지한다. 예를 들면 트랜잭션이 성공하더라도, DB의 유니크 제약 조건이 지켜지는 것을 의미한다. Isolation(격리성) 트랜잭션과 트랜잭션은 서로 영향을 미치지 않아야 한다. Durability(지속성) 트랜잭션이 완료된 것은 DB에 반영되어야한다. 기본적으로 트랜잭션을 이용하면 ACD(원자성, 일관성, 지속성)은 만족한다. 그렇지만 한 가지 만족하지 못하는 것이 있다..
Batch 처리하기 DB에는 수백만건의 데이터를 한번에 처리해야하는 상황도 올 수 있다. 이럴 경우 가장 조심해야 하는 부분은 "메모리 부족 오류"이다. JPA는 영속화를 하게 되며 영속성 컨텍스트의 1차 캐시와 쓰기지연 저장소에 SQL 쿼리를 저장한다. 수백만건을 한방에 처리한다고 하면, 수백만건에 대한 엔티티 + 쿼리가 계속 메모리 상에 저장되고 있는 것이다. 이것은 메모리 부족 오류 문제를 야기한다. 이런 문제점을 해결 하기 위해서는 "나눠서 처리"를 해야한다. 나눠서 DB에 값을 밀어넣거나 가져오고, 필요한 연산을 하고 영속성 컨텍스트를 초기화해준다. 그리고 다시 또 나눠서 처리를 하는 방식이다. 이 경우, 메모리 부족 오류는 개선할 수 있지만 DB 커넥션을 자주 타게 되면서 동작 속도 관점에서는..
N+1문제 N+1은 1번의 쿼리만 의도를 했었는데, 실제 쿼리가 실행되는 시점에서는 쿼리가 N개가 더 나가는 문제다. 이 문제가 일어나게 되면 당연한 이야기지만, 의도하지 않은 쿼리가 나가게 되면서 급격히 성능이 안 좋아지는 것을 느낄 수 있다고 한다. 공부하는 입장에서는 와닿지 않지만, DBA분에게 바로 이상하다고 연락이 온다고 한다. N+1 문제 발생 상황 N+1 문제는 주로 다대일 연관관계의 엔티티를 여러 개를 불러왔을 때 생기는 것 같다. 이를테면 위와 같은 상태에서 자주 발생하는 것으로 보인다. 코드로 하나하나 살펴보려고 한다. 먼저 셋팅 코드를 공유한다. Team teamA = new Team(); teamA.setName("teamA"); em.persist(teamA); Team teamB..
Colletion Join이란? Collection Join은 일대다 관계에서의 Join으로 편리하게 이해하면 된다. 위의 그림을 예로 들어보자. Member Table과 Order Table은 One To Many의 연관관계를 가진다. 이 연관관계에서 Member를 기준으로 Order를 Join 한다고 생각해보자. Member는 Many인 Order를 객체 상태로 가지고 있기 때문에 Collection 형태로 보관하고 있다. 따라서 One을 기준으로 Many를 Join하기 때문에 Collection Join이라고 한다. Collection Join 시 페이징 불가능 Collection Join 시, 치명적인 단점이 발생한다. 바로 페이징이 불가능하거나, 가능하더라도 정합성이 떨어진다는 것이다. 위의 상..