회의 내용

[문제1] 회원의 성향 변화량이 Redis에 계속 쌓일 경우, 해당 데이터는 매우 커질 것으로 예상된다. 이 대용량 데이터를 어떻게 처리할 것인가?

1. MySQL에 ‘자녀 성향 변화량’이라는 테이블을 만들고, 해당 변화량을 업데이트한다.

   1. 3일에 1번, 해당 변화량을 ‘자녀 성향 테이블’에 반영한다. (배치 2개 운영. 비교적 간단)
   2. 변화량이 5가 되면 ‘자녀 성향 테이블’에 반영한다. (자녀성향에 레코드가 덜 생김)

   장점:

   • Redis 메모리 걱정 없이 데이터를 보관할 수 있다.
   • 데이터를 영구적으로 보관할 수 있다.

   단점:

   • 추가 테이블이 필요하다. 이 테이블 또한 관리 대상.
   • 두 개의 배치를 운영해야 한다.

2. Redis에 ‘자녀 성향 변화량’을 저장하는 기존의 로직을 유지하되, 3일에 1번 MySQL의 ‘자녀 성향 테이블’에 반영한다. (배치 2개 운영)

   장점:

   • Redis에 데이터가 너무 쌓이지 않도록 관리할 수 있다.

   단점:

   • 두 개의 배치를 운영해야 한다.

3. ‘자녀 성향 변화량’을 체크하지 않는다. Redis-MySQL의 ‘좋아요/싫어요’ 싱크를 맞추는 일은 매일 1번 수행하며, 이때 ‘자녀 성향 테이블’ ‘좋아요’ 테이블을 모두 해당 기록이 추가된다. (배치 1개 운영)

   장점:

   • 배치 운영이 간편하다.

   단점:

   • ‘ChildTraits’ 테이블에 많은 레코드가 쌓인다.

4. 현재의 로직을 유지하되, ‘자녀 성향 변화량’이 TTL이든, LRU든 시간이 지난 데이터는 자동으로 삭제되게 한다. AOF, RDB를 사용하여 디스크에 저장하는 방법도 생각해 본다.

   장점:

   • 오래된 데이터는 자동으로 삭제가 가능하다.

   단점:

   • 어떤 데이터가 삭제되는지, 삭제되도 되는 데이터인지 판가름하기 어렵다.
   • 자녀 성향이 전혀 변하지 않는 경우가 생길 수 있다.

[문제2] Redis 배치 처리가 가능한가? 배치란 무엇인가?

org.springframework.batch.item.redis 에 있는 클래스를 사용하여 배치 처리 가능함! 하면서 좀 더 찾아보자!

회의 결과

땅땅땅!

1. MySQL에 ‘자녀 성향 변화량’이라는 테이블을 만들고, 해당 변화량을 업데이트한다.

   1. 3일에 1번, 해당 변화량을 ‘자녀 성향 테이블’에 반영한다. (배치 2개 운영. 비교적 간단)
   2. 변화량이 5가 되면 ‘자녀 성향 테이블’에 반영한다. (자녀성향에 레코드가 덜 생김)

   장점:

   • Redis 메모리 걱정 없이 데이터를 보관할 수 있다.
   • 데이터를 영구적으로 보관할 수 있다.

   단점:

   • 추가 테이블이 필요하다. 이 테이블 또한 관리 대상.
   • 두 개의 배치를 운영해야 한다.