본문 바로가기
Projects/OpenRoadmaps

[OpenRoadmaps] 7. 로드맵 뷰어 기능 개발

by DevJaewoo 2023. 2. 5.
반응형

Intro

이전에 로드맵 관련 API를 만들었는데, 로드맵 뷰어 기능을 개발하며 추천 / 로드맵 항목 공부 체크 기능이 들어가며 API에 추천 수, 추천 상태, 공부 완료가 추가되어야 했다.

 

기능을 구현하며 고민한게 2가지가 있다.


고민1: 추천 수 조회 방법

 

사용자가 중복 추천하지 못하도록 하거나 추천을 취소하기 위해 아래와 같이 Client - Roadmap 간의 매핑 테이블을 만들었다.

그런데 추천 수를 가져오려면 매번 테이블 전체를 읽어 추천의 개수를 세어야 하는데, 풀 스캔을 해야 하기 때문에 추천 수가 쌓이면 쌓일수록 성능이 떨어질 것 같았다.

 

매핑 테이블 없이 로드맵 테이블에 likes 컬럼 하나를 추가해 관리하면 count 쿼리를 날릴 필요 없이 추천 수를 바로 읽으면 되어 성능이 훨씬 낫지만, 여러 사람이 동시에 같은 로드맵을 추천할 경우 동시성 문제가 발생할 것이다. 또한 이렇게 관리하면 추천 취소나 중복 추천을 감지할 수 없다.

 

고민 끝에 둘 다 사용하기로 했다.

로드맵 테이블에 likes 컬럼을 추가하고, 추천 시 likes + 1도 해주고 매핑 테이블에 데이터도 추가한다.

그러다 일정 시간이 지나 다른 사용자가 로드맵 데이터를 요청하면 그 때는 매핑 테이블에 count 쿼리를 날려 가져오고, 이를 likes 컬럼에 동기화 해준다.

 

이렇게 하면 count 쿼리의 빈도가 훨씬 줄어들어 정확도와 성능을 모두 챙길 수 있을것 같다.


고민 2: 추천, 로드맵 항목 공부 완료 테이블 구조

위 기능을 구현하기 위해 매핑 테이블이 필요한데, 여기에 데이터를 입력할 때 boolean 컬럼을 만들고 그곳에 Update를 할지, 아니면 row의 유무로 true / false를 판단할지가 고민이었다.

 

결과적으로 boolean 컬럼을 만들기로 했는데, 이유는 다음과 같다.

  1. INSERT / DELETE를 반복하면 ID가 훨씬 빨리 늘어나고, 중간에 구멍이 생긴다.
  2. 나중에 비추천 등의 기능을 만들고자 할 때 데이터의 유무로 판단하는 boolean과 달리 추가적인 컬럼이 필요해 구조를 변경해야 함

(1번의 경우 boolean 컬럼을 만들지 않으면 아무 데이터가 없어 ID도 필요없어지기에 별로 연관이 없는 문제이긴 하다.)


결과

API를 변경해 아래와 같이 응답이 오도록 만들었고, 프론트엔드 로직은 로드맵 에디터에서 복사해와 금방 만들었다.

로드맵 조회 API 응답

 

실행 결과는 다음과 같다.

실행 결과

반응형