2023년 11월 22일 오전 10:00 (GMT+9) @Danny @성우 송 @우진 김

Issue Up 이후

• 답변 사항의 운영 상의 이점에 대한 부분을 감안하여 기존 캐시 서버가 TTL을 관리하는 방식으로 방침을 굳힘

• 의논 중이던 만료 기간 형태 재 의논

  1. 각 캐시 별로 만료 기간을 따로 두는 것.
     1. 튜플 별로 만료 기간을 둘 수 있다.
        1. 관리가 불편할 순 있다.
     2. 조인이 없어 성능에 우위를 가져 갈 수 있다.
  2. 옵션 테이블을 두어 테이블 별로 만료 기간을 관리하는 것.
     1. 수정이 많지 않다.
     2. 관리가 편하다.
     3. 조인이 필수로 발생한다.

• Main 측의 운영, 관리 측의 이점

• 위 사항을 고려해서 옵션 테이블을 두어 만료 기간을 두기로 결정.

• 옵션 테이블을 어떻게 구성할 것인가?

  • 옵션 테이블과 캐시 테이블의 조인 통한 만료 기간 계산을 위해 옵션 테이블에 필요한 속성?
    • 만료 기간은 필수
  • Join을 위해 캐시 테이블과 조인을 할 키 값을 둘 경우 결국 옵션 테이블에 캐시 테이블 튜플 수 만큼 데이터가 생긴다.
    • 옵션 테이블을 두는 이유가 없다!
  • 둘을 별개의 테이블로 두고 계산할 것인가?
    • 조인을 하지 않고 Service 단계에서 캐시의 값과 옵션의 만료 기간을 Select해서 만료 기간을 계산한다.

질문 리스트

@Danny → Cache 만료기간의 대한 설정의 기준이 애매모호하다.

@우진 김 → 수정과 질문의 대한 답변으로 반영을 하자

1. 어느정도 수준까지의 캐시관리를 원하냐.

방안

1. 옵션에 대한 기본키를 테이블명으로 기준을 두자
   1. url ( UserAccount?id=1) 일때 UserAcoount는 테이블명
   2. 즉 option테이블에 테이블명의 기본키를 둬서 구분하자.