MyBatis Cache 란 무엇인가요?

✨ Mybatis Cache 

 캐시 기능 활용 

• 동시 접속자 수가 많아서 성능이 문제가 되는 경우 성능 개선에 MyBatis 캐시가 효과적
• 조회가 훨씬 더 많은 테이블 or Mapper를 통해서만 그 테이블의 데이터가 수정되는 경우

캐시 실행 절차

정보 시스템에서 병목 지점은 대부분 데이터베이스이다.

데이터 베이스의 성능을 향상시키는 것이 정보시스템 성능의 관건이다.

데이터베이스 캐시(cache)가 데이터베이스 성능 향상에 아주 큰 도움이 된다.

Mybatis에서 데이터베이스 캐시는 mapper 마다 따로 생성된다.

✨ 데이터 베이스 캐시 절차

1. mapper의 조회 메소드는 @select(…) 에 정의된 SELECT SQL 명령을 DB에서 실행한다.
2. 조회 결과를 mapper의 캐시에 저장한다. 캐시는 HashMap 형태의 자료구조이다.
3. 조회 메소드 이름과 파라미터 값을 키 로, 조회 결과 value로 캐시에 저장한다.
4. mapper의 조회 메소드는 조회 결과를 리턴한다.
5. mapper의 조회 메소드가 또 호출되면, 조회 메소드 이름과 파라미터 값을 키(key)로, 전에 저장해둔 조회 결과를 캐시에서 찾는다.
6. 캐시에서 찾았다면, DB에서 다시 조회하지 않고, 캐시에서 찾은 조회 결과를 리턴한다.
7. 캐시에서 찾지 못했다면 절차 1번으로 넘어가서, DB에서 조회한다.

*DB 에서 다시 조회하지 않고 메모리에 저장된 데이터를 그냥 리턴하게 되므로 성능 향상 효과가 크다.

---

✨ 데이터 수정 

예를 들어 홍길동 학생 데이터가 StudentMapper의 캐시에 있을 때,

DB에서 홍길동 학생 레코드가 수정되면,

수정된 홍길동 학생 레코드와, 캐시에 있는 홍길동 학생 데이터가 일치하지 않을 것이다.

이 불일치 문제는 다음과 같은 방법으로 해결된다.

1. mapper 에서 insert/update/delete 메소드가 하나라도 실행이 되면, 그 mapper의 캐시를 전부 비운다.
2. 일정 시간 간격으로 mapper의 캐시를 자동으로 비운다.

DB에서 데이터가 수정되는 것을 mybatis가 판단할 때,

mybatis는 오직 mapper의 메소드만 보고 판단한다.

그렇기 때문에, mapper의 메소드를 통하지 않고 DB 데이터가 수정되는 경우에는,

DB에서 데이터가 수정되었다는 사실을 mybatis는 알 수 없다.

DB에서 데이터가 수정되는 것을 mybatis가 판단할 때,

mybatis는 mapper의 @select, @insert, @update, @delete 어노테이션 종류만 보고 판단한다.

@select 어노테이션이 붙은 mapper 메소드는 데이터를 수정하지 않는 것으로 판단하고,

@insert, @update, @delete mapper 메소드가 구체적으로 어떤 테이블의 데이터를 수정하는지와 상관 없이,

오직 그 mapper의 캐시만 비운다.

예를 들어 StudentMapper의 insert 메소드가 호출되면,

StudentMapper의 캐시만 비워지고

DepartmentMapper의 캐시는 비워지지 않는다.

만약 StudentMapper의 insert 메소드에서 Department 테이블의 데이터를 수정했다면,

DepartmentMapper의 캐시는 비워지지 않기 때문에 수정되기 전 데이터가 캐시에 들어있게 된다.

그래서 DepartmentMapper의 캐시와 Department 테이블의 데이터가 불일치하는 문제가 발생하게 된다.

 

❗️따라서 mapper를 구현할 때 다음 규칙을 지켜야 한다.

1. 테이블 마다 mapper를 따로 구현한다.
2. 데이터를 수정하는 SQL문은 그 테이블의 mapper에만 구현한다.

*위의 상황을 다 지켜도 데이터 불일치가 발생할수 있다. ( 테이블 JOIN )

 

동시 접속자가 많은 네이버 뉴스의 첫 페이지가, 1초 동안 평균 만번 조회된다고 할 때,

1초 시간 간격의 DB 캐시가 있다면,

1초에 1만 번이 아니라 한 번만 DB에서 기사 목록을 조회하면 되고,

9999번은 캐시에서 기사 목록이 리턴될 것이다.

1초 동안 1만번의 조회가 1번으로 줄어들기 때문에 성능 향상 효과가 매우 크다.

동시 접속자 수가 많을 수록 그리고 자주 수정되지 않는 테이블일 수록

데이터베이스 캐시의 성능 개선 효과가 크다.

네이버의 카페 게시판, 블로그, 뉴스 사이트들의 경우에 데이터 수정은 아주 드물고, 동시 접속자 수는 아주 많다.

카페, 블로그, 뉴스 모두 최신 데이터 위주로 조회된다.

과거 데이터는 엄청 많지만 거의 조회되지 않는다.

뉴스의 경우 조회가 몰리는 데이터가 몇 개 되지 않는다.

위와 같은 사이트들에서 데이터베이스 캐시의 성능 개선 효과는 매우 클 것이다.

 

✨ 캐시 구현 

mybatis mapper 클래스에 @CacheNamespace 어노테이션만 붙여주면 캐시 기능이 활성화 된다.

*(캐쉬 기능 구현은 사소할 정도로 간단하다. 이 기능을 잘 이해하는 것이 중요)

 mapper 클래스 수정 

•  @CacheNamespace(flushInterval=1000, size=2048)
• flushInterval은 캐시가 자동으로 비워지는 시간 간격이다. (단위 밀리초)
• size - 캐시의 크기를 지정한다. 캐시에 저장할 조회 결과의 수 (생략 가능)
• 시간 간격이 짧을 수록 데이터 불일치 발생 기간이 짧아진다.

 

mapper

 DTO 클래스 수정 

• implements Serializable
• private static final long serialVersionUID = 1L;

dto

mybatis cache 의 기능은 다음과 같다.

1. select 태그로 정의된 모든 mapper 메소드의 조회 결과가 캐시에 저장된다.
2. insert/update/delete 어노테이션로 정의된 메소드가 호출되면 그 mapper의 캐시가 전부 비워진다.
3. 조회 결과는 최대 1024개만 저장된다.
4. 캐시가 꽉 차면 먼저 LRU(Least Recently Used) 항목을 제거하고 새 조회 결과를 저장한다.
5. LRU = 데이터 사용 시각이 가장 오래된 항목

 

돈 관련 테이블이나,

수강신청 테이블 처럼 잠깐의 데이터 불일치도 허용할 수 없는 테이블에는 cache 기능을 사용하면 안된다.❌

학과명 테이블이 cache를 사용할만한 테이블이다.

학과명은 거의 수정되지 않고, 만약 수정되어도 1초 정도 학과명 불일치는 별 문제 아니다.