[데일리 스크럼] 12 08

12.08 (목) 데일리 스크럼

MySQL, mongoDB 둘다 사용하는 이유

• MySQL 사용하는 이유
  • 초기 서비스 설계단계에서 사용자와 관계가 생기는 댓글, 좋아요, 마이페이지 기능들을 생각했었다.
  • 나중에 이러한 기능들의 추가를 예상해 사용자 데이터를 MySQL에 저장함.
  • 예를들어 mongoDB 사용시 설문지가 댓글을 임베드해서 갖고 있는다면 설문지에 빈번한 수정이 발생한다.
    • 사용자 A의 닉네임 변경 ⇒ mongoDB에 있는 A의 댓글 전체 수정
    • mongoDB의 join은 성능이 떨어진다.
• mongoDB 사용하는 이유
  • 유연한 데이터 구조
  • 설문지나 응답지의 경우, 관계성이 복잡하게 나타나지 않음
  • 설문지, 응답지의 특성 상 내부에 배열 형태의 데이터가 저장되는 경우가 많음
    • embedded document를 지원하는 mongoDB가 적합하다고 판단
    • 또한 설문지의 특성 상, 수정되는 일은 적고 응답을 위해 호출되는 경우는 많다고 판단하여, 읽기 속도가 빠르고 수정 속도가 비교적 느린 mongoDB가 적합하다고 판단
  • 서비스 구조 상 CRUD 작업은 항상 데이터 객체 단위(설문지, 응답)로 진행되어 속도 향상에 유리
  • 서비스 구조상 설문지나 설문지 응답 단위로 데이터가 사용된다. 만약 RDB를 사용해 설문지를 저장했다면 사용자 - 설문지 , 설문지 - 문제, 문제 - 옵션, 이렇게 정규화 되어 저장이 되고 설문지가 읽힐 때 마다 조인이 발생한다. mongoDB에서 설문지 단위로 저장을 하면 빠르게 읽기 작업을 수행 할 수 있다. 수정에 있어서는 정규화되어있는 RDB가 효율적이지만 일반적으로 데이터에대한 수정보다는 읽기 작업이 많이 발생한다.

어제 한 일

• 강년
  • 로그아웃 시 redirect해서 발생하는 오류 수정
  • 설문지 결과 API 리팩토링
    • mongoose lean 적용
    • 비동기 병렬 처리
    • 응답 schema의 form_id 에 인덱스 적용
  • NginX 도입한 서버에 CD 적용
• 성호
  • 설문지 응답 및 수정 제출 API에서 Caching 적용
    • class 형태로 리팩토링
    • 500 Error 발생하던 오류 수정
• 도희
  • 카드 컴포넌트 구현
  • 카드 컴포넌트를 활용하여 내 설문지 페이지 디자인 수정
    • 디자인의 통일성 확보
• 현택
  • 게시판 페이징 구현
  • 리팩터링

오늘 할 일

데모준비

• 도희
  • 내 설문지 페이지 무한스크롤 적용
  • 스켈레톤 컴포넌트 구현 및 적용
• 강년
  • 도메인 설정
  • 리팩토링 및 버그 수정
• 성호
  • 리팩토링
    • redis에서 mongoDB로 데이터 옮기는 스케줄러 분리
    • 스케줄러 CI/CD 구현
• 현택
  • 게시판 api 수정 사항 반영 (accept_response, category)
  • 게시판 최대 페이지 수 캐싱