티스토리 뷰

⚠️ 특정 비즈니스 상황을 천천히 생각해 보면서 작성한 글입니다. 허술함에 주의하세요.

이벤트 '시작 시각'과 이벤트 '종료 시각'을 담고 있는 데이터가 있다.

ID 시작시각 종료시각  
1 2023. 8. 20 00:00 2023. 8. 25 23:59  
2 2023. 8. 26 00:00 2023. 8. 30 00:00  

특정 시점(=현재시각)을 기준으로 이벤트 중인 데이터를 조회

 특정 시점을 기준으로 이벤트 중인 데이터를 조회하는 기능이 있다고 하자, 위 데이터가 SQL 서버에 저장되어 있다면 손쉽게 쿼리로 원하는 데이터를 추출할 수 있을 것이다.

 

캐시 적용

 데이터가 매우 많고, 호출이 많아 위 기능에 캐시를 적용하기로 하였다. 어떻게 적용하면 좋을까?

아마도 위 기능을 구현하는 함수는 아래와 같은 형태이고, 인자 값인 `at` 은 호출 시점마다 다른 값으로 호출한다면, `@Cacheable` 로 좋은 성능을 얻기 힘들 것이다.

fun getInProgressEvents(at: LocalDateTime)

제약 조건

캐시를 효율적으로 설계하기 위해서 막강한 함수에 제약 조건을 조금 추가해서 상황을 좀 더 단순화 할 필요가 있어 보인다.

 

제약 1. '현재' 유효한 이벤트만 읽어올 수 있으면 된다.

위 데이터 기준으로 21일 유효한 이벤트만 가져오면, 레코드. 1을 가져오게 된다.

이 데이터를 캐싱하게 되면, 2023. 8. 26일 00시에 이벤트 2가 리턴돼야 함으로 기존 캐시가 만료되어야 한다. 즉, 제약조건이 포함되기 전 문제가 여전히 발생함

 

방법 1. '현재' 이후, 가능한 이벤트를 모두 가져온다.

'종료시각' 기준으로 현재 진행 중인 이벤트와 예정 중인 이벤트를 모두 가져온다. 그리고 이 값을 캐싱한다.

실제 진행 중 인 이벤트는 웹서비스에서 판단해서 응답한다.

@Cacheable
fun getInProgressAndFutureEvents()

 

예정된 이벤트가 매우 많다면,

적당히 효율적인 단위로 낮춰서 캐시를 적용하는 수밖에 없을 것 같다.

@Cacheable
fun getInProgressEvents(on: LocalDate)

 

공지사항
최근에 올라온 글
최근에 달린 댓글
Total
Today
Yesterday
링크
«   2024/04   »
1 2 3 4 5 6
7 8 9 10 11 12 13
14 15 16 17 18 19 20
21 22 23 24 25 26 27
28 29 30
글 보관함