음식점 조회수 테이블 분리하여 저장하는게 어떨까요?

[TaeyeonRoyce]

상황

음식점 상세 조회 시 조회수를 응답해야 하는 상황
[음식점 조회수] 라는 데이터를 저장해야 한다.

조회수 특징

조회수를 증가 시키는 쓰기 작업이 상당히 많이 발생하고 동시에 발생할 가능성이 많이 높음

방안 1. 음식점 테이블에 조회수 column 추가하기

제일 직관적이고 간단한 방법
하지만, 요청이 올 때 마다 음식점 테이블을 잠그게 되고 viewCount가 계속 변경됨.
조회수 특징을 고려해보면, 아무리 간단한 방식이지만 개선이 분명하게 필요함.

방안 2. 조회수를 테이블로 분리

조회수 때문에 발생하는 음식점 테이블에 대한 Lock을 피할 수 있음.
관심사를 분리하여 쓰기 작업에 대한 동시성 문제 개선 시에도 음식점 Table에 영향을 주지 않을 수 있음.

---

저는 [방안2]로 구현하고자 하는데 다들 어떠신가요?
만약, 채택된다면 다음과 같은 변경사항이 예상됩니다.

• 음식점조회수 table 추가
• Restaurant Entity에 @OneToOne 컬럼 추가

더 좋은 방법 & 참고

• https://tecoble.techcourse.co.kr/post/2022-10-10-like-count/
• https://velog.io/@juwonlee920/Spring-%EC%A1%B0%ED%9A%8C%EC%88%98-%EA%B8%B0%EB%8A%A5-%EA%B5%AC%ED%98%84-%EC%A1%B0%ED%9A%8C%EC%88%98-%EC%A4%91%EB%B3%B5-%EB%B0%A9%EC%A7%80

[shin-mallang]

조회수가 10만이라면, 10개의 row가 생기는건가요?

[TaeyeonRoyce]

아뇨, 음식점이 10만개면 10만개의 row가 생깁니다.
구상은
restaurant_view_count

• id
• restaurant_id
• count (조회수)
  이렇습니다!

[shin-mallang]

아 10만 치려 했는데 만이 빠졌네요 ㅋㅋㅋㅋㅋㅋ

제 의견은 조회수가 그렇게까지 정확성이 중요한 데이터가 아닌데, 이를 위해서 불필요하게 데이터베이스를 사용하는게 아닐까 싶네요.

[TaeyeonRoyce]

Transactional level이 Repeatable read라서 고려했던 조회시의 성능저하는 없군요.
분리는 고려하지 않고 테이블에 컬럼으로 추가하겠습니다

[kdkdhoho]

3번 Sync Schedule 방법은 어때요?

쓰기와 읽기 테이블 분리로 인해 서로 영향을 주지 않을 수 있을뿐더러, viewCount를 다른 테이블로 빼서 생기는 join도 피할 수 있을 것 같은데욥!

[TaeyeonRoyce]

정확도도 필요하면 Sync하는 작업을 고려해도 괜찮을 것 같은데, 추후 도입할게요.
우선은 최소 비용으로 조회수 기능을 추가하는게 목적이라 1번을 하려 했었거든요.

현재 방식에서는 좋아요와 달리 조회수는 한명의 유저로도 100건 넘는 값 수정이 가능해서 sync 주기도 짧아야 할 것 같아서요!