[WIL] 조회수 기능 개발 1

sns를 사이드 프로젝트로 개발하고 있는데 조회수 기능을 개발할 일이 생겼다.

사실 조회수를 어떻게 측정하느냐도 중요한데 추후 변경될 수도 있으나 현재 기획은 이렇다.

• 사용자가 웹피드(타임라인)을 조회했을때 조회되는 게시글들은 전부 조회수+1
• 특정 게시글 상세보기를 한다면 조회수+1

현재 Post(게시글) 테이블이 이렇게 되어있다고 할때

조회수 테이블을 어떻게 생성하는게 좋을까 생각해보았다.

첫번째는 POST 테이블에 VIEW_COUNT 컬럼을 추가하는 것이고

두번째는 VIEW라는 테이블을 따로 생성해 POST_ID를 FK이면서 동시에 PK로 놓는것이다.

 

사실 처음엔 SNS라는 도메인 특성상 POST테이블은 게시글 CURD외에도 여러가지 이벤트가 일어날텐데 조회수 추가라는 이벤트까지 추가해 특정 테이블에 작업이 몰리게 하는 것보다 테이블을 따로 생성해 해당 테이블로 처리하는 게 나으리라고 판단했다.

조회수의 특성을 생각해보았을때 데이터가 날라갔을때 상대적으로 덜 치명적이지만 그만큼 더하는 연산이 자주 일어날테니까 Redis같은 인메모리 DBMS를 사용하고 하루에 한번씩 VIEW_COUNT라는 컬럼에 업데이트를 해주는것으로 처리하면 첫번째 방법으로 해도 되지 않을까라고 결론냈다.

 

그러나 그걸 감안해도 조회수 조회라는 것은 결국 POST테이블의 VIEW_COUNT를 UPDATE하는 작업이다.

게시글 조회라는 이벤트는 많이 일어날테고 UPDATE되는 데이터의 양이 많다면 역시 VIEW를 테이블로 따로 빼서 업데이트해주는 것이 동시성 제어 측면에서도 효율적이라고 생각했다.

 

예를 들어 조회수를 일괄적으로 UPDATE하기 위해 로우마다 락을 걸어 업데이트하고있을때 사용자가 게시글을 수정하지 못하는 상황이 일어난다면 어떡할것인가, 조회수보단 게시글 수정 데이터가 더 중요하다고 생각한다.

그리고 만에하나 게시글 테이블 구조를 급하게 변경해야하는데(그럴리는 없지만) 테이블락이 걸려있어 구조를 변경하지 못한다면!?

 

그렇기에 조회수 테이블을 따로 생성하는 쪽으로 결정했다.

그리고 조회수 업데이트 구상도 이다, 아마 차차 구현하면서 세부적인 것들이 정해지겠지만 대략적인 구상도는 이렇다

 

오늘의 참고한 글

https://untitledtblog.tistory.com/131

[관계형 데이터베이스] - 동시성 (Concurrency)

https://ysyblog.tistory.com/233

[SQL 튜닝] Lock과 트랜잭션 동시성 제어