1) readme.MD 잘못된 표현들 정리
프로젝트 중요 목표 정함
2) ERD 설계
카테고리, point, 2인실 필드 등 지우는 게 낫다.
핵심 빼고는 안하는 게 나음(협의)
StudyGroup-Room 관계 다대다인지 일대일인지?
결론 : 연관관계가 없는 걸로 따로따로, 중간에 Reservation이 있기 때문에.
3) API 명세서 가이드 확인
room/{roomId}reservation/{reservationId}
: @PathVariable 엔티티 식별자로 앞에 있어야 함4) 스케쥴러
SimpleAsyncTaskExecutor()
방식 찾음5) 더블 부킹
JPA 비관적 잠금(Pessimistic Lock)
확인 - 트랜잭션끼리의 충돌이 발생한다고 가정하고 우선 락을 거는 방법, DB에서 제공하는 락기능임.@Lock(LockModeType.PESSIMISTIC_WRITE)
@Query("select r from Romm r where r.id = :roomId")
or Update시 Lock
SELECT FOR ~ UPDATE 쿼리
: 동시성 제어를 위해 특정row에 배타적 LOCK을 거는 행위
“데이터 수정하려고 찾은 것이니, 다른분들은 건드리지 마세요!” 뜻임!
1) 알고리즘 공부
DFS - 인접 행렬
, 인접 리스트
방식에 따른 다른 방법 구현 -> 시간복잡도 정리
: https://velog.io/@mooh2jj/DFS깊이우선탐색-BFS너비우선탐색
이진탐색 - 시간복잡도 O(logN)
: https://velog.io/@mooh2jj/알고리즘-자료구조-시간복잡도-정리
2) JPA Data 레포지토리 EntityManager, 쿼리메서드, @Query 등 정리
5) 프로젝트(피드백한 내용 정리)
readme.md 정리
서버 구조도, 배포 구조도 업데이트 중
push vs pull - 뉴스피드 생성 GET 방식의 방법들임.
push : 쓰기 시점에 미리 팬아웃 하는 모델. 읽을 때 나오는 게 빠르다/ 자원낭비가 있다.
pull : 읽기 시점에만 팬아웃 하는 모델. 자원낭비가 거의없다. / 읽는데 시간이 걸린다. => 요청이 올때만 그때 한다 // 비동기가 아니다.
정리 : 자원낭비가 거의 없는 pull 방식
으로 뉴스피드 방식을 써야 되지 않을까 싶다.
관련 블로그 : https://os94.tistory.com/186 중 pull vs push PART
4) 책
1) 알고리즘 시간복잡도
에 대한 중요성 다시 언급
2) user , studyGroup 테이블의 매핑 테이블로 user_group 착안
reservation안에 위 3개 테이블의 pk들을 외래키로 사용
3) 더블 부킹 내용은 Reservation DB pk를 String으로 놓고 atomic을 보장케 하는 방향으로.
100||2022041210
(2022년 4월 12일 10시 룸 100) 방식으로. 4) 15분 간격 + 30분 간격 겹치는 건 어떻게 해결?
: 4개의 로우를 만들어 겹치지 않게 코드로 구현
5) 책 <가상 면접 사례로 배우는 대규모 시스템 설계 기초> 내용 언급 - 인터뷰용으로 아주 좋다고 추천
멘토님과 <ward-study 프로젝트> 기술면접식으로 질문과 답변이 오갔다. 예상대로 역시나 빡셌다.. 4주차
DB Reservation 설계가 너무 어렵게 느껴진다. 양방향 매핑이 들어가니.. 매핑테이블의 존재를 몰랐으면 어렵게 설계할 뻔 했다.
DB로 더블부킹을 막는 방법에서 내가 생각한 방법 또 반려. DB pk가 이미 Atomic이 default였다니 처음 알게되었다.
스프링 배치보단 일단 DB 설계에 집중해야겠다. 사실 직접 설계를 한다면 좀더 파악이 쉬울 거란 생각도 든다. 만들어보지 않은 채 얘기만 하니 너무 힘들다... 다음 멘토링 전에는 내 애로사항을 얘기해 봐야겠다.