블로그 프로젝트에 추가할 좋아요 기능에 대한 고민이 생겼다.
프로젝트는 sequelize를 사용하여 블로그 백엔드 api 부분을 구현하는데 좋아요 기능 구현 방식이 문제였다.
스터디 인원들과 고민을 해봤는데, 일단 db자체에서 카운팅을 하거나 혹은 받아온 이후에 좋아요 개수를 세어서 좋아요 카운트를 보여주는 것은 비효율적이라는 의견이 많았다.
좋아요 건 수가 작을 경우에는 큰 문제가 되지 않겠지만, db에서의 카운팅 연산 자체가 속도가 느린편이기에 해당 데이터가 많이 쌓일 경우에는 과도한 시간이 걸릴 가능성이 존재했다.
그에 대한 해결 방안으로 Posts 테이블 안에 likeCount 칼럼을 생성하여 특정 유저가 좋아요를 클릭 할 경우 likeCount를 +1 시켜주는 방식을 취하고자 했다.
여기에 더해서 같은 게시글에 대하여 같은 유저가 여러번 좋아요를 클릭하는 경우를 막아야 하기 때문에 따로 유저의 id를 유지해야하는 소요가 생겼다.
이에 대해서 두 가지의 방법을 생각해보았는데,
첫 번째는 게시글에 likeList 칼럼을 생성하여 유저가 좋아요를 눌렀을 경우, 그 안에 배열로 userId값을 저장하고 다시 클릭했을 때 likeList 배열 안에 userId값이 이미 존재할 경우 배열 안에서 userId값을 삭제하는 방법.
두 번째는 새로운 테이블을 만들어서 postId를 키 값으로 userId를 따로 저장하는 방법이다.
일단 첫 번째의 제한사항은 db의 필드에 저장할 수 있는 최대 글자 수가 제한적이라는 것이었다.
따라서 좋아요의 최대 개수를 제한하지 않을 경우 해당 방법은 사용할 수가 없었다.
또한 최대치의 배열까지 사용한다 하더라도 해당 배열을 불러와서 다시 비교를 하여 연산을 해야하는 등 복잡한 방식이 필요하다고 생각했다.
두 번째 방법의 경우 내가 고민했던 것은 find나 여타 db에서 연산을 하게 될 경우, db 통신 비용이 발생할 지가 궁금했는데 해당 부분에 대해서는 find와 같은 연산의 경우에는 비용이 발생하지 않고, 실제로 넘어오는 특정 건에 대해서만 발생한다는 답변을 들었다.
(100건에 대해서 findOne의 경우 100건을 살펴보는데에서는 비용발생 x, 넘어오는 1건에 대한 통신비용만 발생, 단 AWS RDS의 경우이다. 다른 데이터 베이스 사용 때는 불확실하다...)
정리하자면 다음과 같다.
1. 게시글 테이블 안에 likeCount 칼럼을 추가하여 카운트 연산의 소요를 없앤다.
2. 새로운 테이블을 작성하여 postId와 userId를 저장하여 사용하는 것으로 좋아요 수의 최대치 제한과 배열 연산의 소요를 없앤다.
