[실전프로젝트 26Day] 오늘의 나는

이번주에 들어서부터 여러 기능을 조금씩 파기보다는 한 기능에 집중해서 분석하고 공부하는 시간을 가지고 있다

그게 진정한 챌린지팀의 묘미라고 해서 ,, 👀

 

월요일에는 테스트코드(Junit), 동시성제어에 대해서 공부를 하였고

화요일~수요일에는 공부한것을 바탕으로 내 프로젝트에 적용해보고, 내가 성능 개선할 기능에 대해 뜯어보는 시간을 가졌다.

아래의 내용은 오늘 내가 기능을 뜯어보면서, 어떻게 구현할지 고민을 한 부분이다 ! 

 

---

스토어 정보 업데이트, 어떤 시점에 어떻게 처리해야할까 ? 🤔

기능 :

• 스토어정보(별점 & 방문자 리뷰 갯수) 업데이트 기능

기능 명세 :

• 정보가 업데이트 된 스토어가 있을 경우 주기적으로 확인하여 정보를 갱신하는 기능

구현 방향 :

• 사용자 리뷰 등록 시 상태가 업데이트 된 스토어 정보(ex. 스토어 ID, 별점 등)를 Redis Cache에 저장
• Redis에 저장된 정보를 일정 주기마다 읽어서 변경된 정보를 Store 테이블에 업데이트 처리
  ⇒ 이 부분을 어떻게 처리할지에 대한 고민 !!

---

기술적 고민:

 

1) Redis에 어떤 정보를 저장하고, 어떻게 사용할것인지?

*) Redis Cache에 데이터 저장방식은 Set 방식으로 저장됨(중복된 값 저장 X)

 

Case1 . 업데이트 된 스토어 ID 정보만 Redis Cache에 저장(새로 적용한 방식)

• 업데이트 된 스토어ID만 저장하고 Review 테이블에서 스토어ID와 일치하는 레코드들을 조회하여 스토어 정보를 갱신하는 방법
• 배치프로그램이 동작하기 이전에 몇개의 리뷰가 등록되었는지 체크하지않고, 업데이트가 되었는지/안되었는지만 확인하여 
  Redis에 정보가 변경 된 StoreId를 저장하는 방식

 

쿼리문 및 실행 속도

// 사용하는 쿼리문

UPDATE store a 
SET 
a.review_cnt = ( SELECT count(*) FROM review where storeid = 스토어ID),
a.star_score = TRUNCATE((select avg(star_score) from review where storeid = 스토어ID),2)
WHERE store_id= 스토어ID;

⇒ Thoughput : 1.1/sec , 최소시간 20 / 최대시간 511

 

 

 

Case2 . 업데이트 된 스토어 ID , 별점 정보, 사용자 정보 Redis Cache에 저장(기존 적용 방식)

• 업데이트 된 스토어ID 및 갱신된 정보들을 저장하여 Redis에 저장된 정보로 DB에 업데이트 하는 방법
• Redis Cache에 있는 데이터를 기반으로 Store 정보를 업데이트 하는 방식 캐시에 저장되는 데이터의 무결성이 중요함!

 

쿼리문 및 실행 속도

// 사용하는 쿼리문

UPDATE store a 
SET 
a.review_cnt = review_cnt + 1, 
a.star_score = TRUNCATE (((((review_cnt - 1) * star_score) + 입력된 별점) / review_cnt), 2) 
WHERE store_id= 스토어ID;

⇒ Thoughput : 1.1/sec , 최소시간 17 / 최대시간 154

 

---

2) 두가지 방식 비교

• 실행 속도 :
  ⇒ Case 2 방식이 Case 1 방식보다 수행 속도는 약 3배 느림
  
  
• 반복 횟수 :
  ⇒ Case 1 방식은 1번  / Case 방식은 10번의 쿼리가 수행 됨
  ⇒ Case 1 방식은 4번 / Case 2 방식은 40번 수행 됨
  
• 상황 별 테스트 케이스 :
  상황 1. A 스토어 리뷰가 10개 등록 되었을 경우
      ⇒ Case 1 방식은 1번만 쿼리 / Case 방식은 10번의 쿼리가 수행
  
  상황 2. A,B,C,D 스토어에 리뷰가 각각 10개씩 등록되었을 경우
     ⇒ Case 1 방식은 4번 쿼리 질의 수행 / Case 2 방식은 40번 수행 됨

---

고민했던 점 ❓

 

Q.

쿼리 수행 시간 자체는 감소되지만, 많은 쿼리를 날리게 되는 Case 2 방식을 사용하는게 효율적일지?

수행시간은 증가되지만, 적은 쿼리를 발생시키고 Redis Cache에 데이터를 적게 적재하는 1 방식이 효율적일지?

 

• Case1을 적용하고, 쿼리 시간을 감소 시킬 수 있는 방안에 대해 고민하는것이 좋을 것 같음!
• Case2 방식으로 사용하였을 때 DB에 상당한 부담을 줄 수 있을 것이라고 판단
  ⇒ 부담도 줄이고, 쿼리 수행 속도도 줄이는 방향으로 고 !
  ( 1차 적용 : View 테이블 생성 및 적용 )

 

Q.

Case 1 방식을 사용할 때 꼭 Redis Cache를 사용해야할까?

아니면 다른 대체 방법이 어떤것이 있을까? 🧐

 

• 리뷰 등록 시 Review 테이블에 식별자를 주어 구별하는 방법
  ⇒ 배치 서비스에서는 DB에서 UpdateInfo가 True인 Store정보만 업데이트
  ⇒ Review Table에 UpdateInfo 라는 컬럼을 추가하여 리뷰 등록 시 True로 값을 변경한다.

---

이 밖에도 동시성 제어 부분을 고민하고있는데 지금까지 테스트 한 것으로는 위의 방식을 적용했을 때 

동시성 이슈가 발생하지 않는다 (클라이언트가 여럿이여도 DB에 업데이트하는 주체(Redis)는 한개이기 때문임) 
내일 조금 더 고민해보고 다른 부분에서 동시성 이슈가 터질만한 부분은 없는지? 추가해서 글 작성해둬야겠당