엔터프라이즈 ORM과 1차캐시

DB CRUD 작업을 쿼리없이 ORM을 처리하면 참 편리한데,

여러 언어들과 다양한 ORM들의 차이를 이해하지 못하면, 난감한 상황이 발생하곤 한다.

기본적인 ORM의 뜻대로, 객체와 매핑이 되는건 동일하지만

동적 타입 언어들과 정적 타입 언어들은 확실히 다르다.

 

난감한 상황으로써, ORM의 1차캐시에 대해 알아보자.

 

Java진영의 JPA를 예로 들면, Persistence Context (Enitity Manager) 에서 1차캐시를 관리한다.

같은 객체를 한번만 조회하고, 이후에는 캐시에서 읽는 효율적인 쿼리동작을 가능하게 한다.

1차캐시를 기반으로, CRUD가 즉시 실행되지 않는 형태가 많다. (장점이자 단점인 부분)

 

전제

>> 1차 캐시는 "트랜잭션 범위 메모리 캐시"이다. DB와 동기화되기 전까지는 메모리 상태가 진실처럼 동작합니다.

 

문제점 1. 긴 트랜잭션시 메모리 문제

대량의 데이터를 입력한다고 가정하면, object 추가시, 먼저 캐시에만 등록되는데 메모리를 많이 사용하게 되므로, 주의해야한다.

단일 트랜잭션으로 대량 데이터 입력시에는, 1차캐시는 독이다.

 

문제점 2. 오래된 데이터 문제

어플리케이션 서버가 1대가 아니거나, 외부에서 DB가 변경된 경우, 1차캐시를 통해 읽은 데이터는 최신 데이터가 아닐 수 있다.

필자가 겪은 모든 문제의 근원이었다. 동시성을 요하는 상황에서, 설계가 잘못되면, 지옥문이 열리게 된다.

 

문제점 3. 객체 동일성 보장이 문제가 되는 이슈

동일 Id값을 조회된 entity는 같은 객체가 되는데, 다른곳에서 의도하지 않은 동일 객체 변경을 해버리면, 또 지옥문이 열린다.

 

문제점 4. JPQL과의 충돌

필요에따라 raw 쿼리를 사용하려다가 JPQL등을 섞어버리면, DB 값과 1차캐시내 객체의 값이 달라질 수 있다.

 

문제점 5. Write-behind로 인한 착시

객체를 조회 후, 변경했지만, DB반영 시점은 다르다. 정합성이 깨지는 상황이 빈번함을 인지해야 한다.

해당 서버에서는 같은 객체로 변경된 값을 읽겠지만, 완전한 DB반영이 되었다고는 생각하면 안됨!

 

문제점 6. 대규모 루프 처리 시 성능 저하

대량 루프를 통한 entity 작업을 수행하면, 1번 문제점과 비슷한 상황이 발생한다. 변경감지 비용도 대폭 증가해 성능도 안좋다.

(대규모 처리에는 자원낭비만 하는 꼴)

 

문제점 7. 클러스터 환경에서는 의미 없음

1차캐시는 서버간 공유되는 개념이 아니니, 어차피 서버마다 따로 관리가 됨.

클러스터 환경이라면 실제로 효율적인가? 의문

 

게임서버, 금융시스템 등, 고동시성 + 실시간 정합성이 중요한 시스템에서는 사용시 장점보다 단점이 많을 수 있다.

단일서버 + 단일트랜잭션 구성으로 백오피스 등에서나 사용할만한데, 이게 왜 엔터프라이즈??

 

ORM의 1차캐시 장점

1. 동일성 보장

2. DB접근 최소화로 성능 향상

3. 변경감지를 통한 자동 Update

4. 쓰기 지연을 통한 성능 향상

5. 객체 그래프 관리 (연관관계 자동관리)

6. 트랜잭션 단위 일관성

7. 복잡한 도메인 모델 관리 용이

도 많으니, (장점이자 단점인 것들이 많긴하다) 잘 사용하면 정말 좋은 기능이다.

 

 

결론:

ORM 사용시 1차캐시가 존재하고, managed entity로 관리되는지, 명확하게 짚고, 설계,개발시 고려해야한다.