현재 몽고디비의 collection
현재 몽고디비의 Document에는 게시글을 작성한 유저로 User 테이블의 PK 값을 가진 userId를 저장하고 있다.
현재 게시글 조회의 로직
현재 게시글에 대한 데이터를 가져오기 위해선 아래의 사진과 같이
몽고디비의 데이터에서 해당 userId 를 가진 Document를 조회한 후
Mysql에서 해당 유저의 프로필 정보를 가져온다.
몽고디비인 Nosql의 장점으로는 리드연산이 빠르다는 장점을 가지고 있다.
하지만 중간에 Mysql 커넥션이 들어간다면 몽고디비의 장점인 리드연산이 사라진다고 생각했다.
문제 해결 방향
해당 문제점을 해결하기 위해선 몽고디비의 게시글 조회 과정속에서 Mysql과의 커넥션이 없어야한다.
이를 해결하기 위한 방법을 생각해본 결과
- 글을 작성할때 Mysql에서 해당 유저의 프로필 정보를 조회하여 글작성시에 프로필정보까지 저장한다.
- 이 과정은 역정규화를 사용할 수 있다.
이 과정의 문제점
- 유저가 게시글을 작성할때 해당 유저의 프로필을 조회하는 Mysql 커넥션이 들어가니깐 작성에서 쿼리가 한번 나가게된다.
- 유저가 프로필을 수정할때 해당 유저가 프로필을 수정하기 전 작성한 게시글의 유저 프로필도 수정해줘야한다는 것이다.
해당 문제 해결 방향의 4줄 요약
- 몽고 피드 리드 시간 개선할려고함
- 지금은 몽고 피드를 리드할때 mysql에서 유저 프로필을 가져와야함
- 고민했던 방향은 피드를 작성할때 작성자 정보를 같이 넣는거
- 하지만 수정했을때 mysql 유저 정보 포함 피드의 모든 유저 정보도 변경해줘야함
결국 이 문제는 조회에서 장점을 얻을 수 있지만 작성과 수정에서 문제가 발생하는 트레이드 오프이다.
문제의 예시 사이트
리그오브레전드의 승률 사이트인 op.gg과 같은 사이트에서는 전에 게임을 진행했던 유저 리스트와
해당 유저의 프로필을 들어갔을때 유저의 정보가 다른 경우가 있다.
해결 방향
프로필 문제는 주기적으로 일정시간에 한꺼번에 게시글들의 프로필을 수정한다면 해결할 수 있는 문제이다.
추가적인 다른 개선방향
- 피드보여줄때 그 리스트들만 몽고를쓰고 디테일한 피드를 보여줄때는 mysql로 다 처리하는 로직으로 진행한다.
를 생각했다 하지만 이 방법은 구조를 바꿔야 된다고 생각한다.
2. 캐시의 개념을 도입
- 모든 정보를 가지고 있지 않으면서 항상 최신화되어 있을 필요도 없다.
- 특정 시점에 업데이트 해줘도 상관 없다.
의 형태를 가지고 있기 때문에 캐싱을 해주는 것도 괜찮으며 캐싱을 위한 특정 기술스택을 굳이 도입하지 않아도
mysql이나 몽고DB에서도 캐싱의 형태로 구현할 수 있다.
'Spring' 카테고리의 다른 글
[Spring] 몽고디비 read 개선 방향 - 2 (0) | 2022.02.17 |
---|---|
[Spring] @RequestBody 어노테이션 사용 요청 매핑 문제 (0) | 2022.02.13 |
[Spring] 서버와 클라이언트 소켓 통신 문제 (0) | 2022.02.13 |
[Spring] Request Mapping Null (0) | 2022.02.13 |
[Spring] HashMap 데이터 삽입시 key의 순서 정렬 문제 (0) | 2022.02.13 |
댓글