📌 11주차 이후 질문 및 정리
0) measureable 수치
tps- transaction per secqps- query per sec
: 다른 관점으로 살펴야 거의 비슷하다.- 관련블로그 : https://intrepidgeeks.com/tutorial/significance-and-calculation-method-of-qps-and-tps-in-mysql-database
1) DB 설계
-> DB Lock vs 더블 부킹(중복 예약)
2) newsfeed push or pull 모드 장단점
3) API 명세서를 두고 이야기
: REST API 관련 설계 양식대로, 엔티티 순서 등
-> gitbook 으로 정리
4) Notification 스케쥴러
: spring batch 알아보았지만 실시간 trigger의 존재가 없었음 vs AWS step function 기능
: scheduler(Quartz) 알아봄
5) 중요 엔티티 설정 : DB 매핑
그 바탕으로 ERD 설계, 핵심은 1:N, N:N 양방향 매핑
📌 전주 개인 공부한 내용들
1) 알고리즘 공부
- DFS : 이러테이티브, 레커시브(재귀함수)
- String : 문자열 뒤집기(팰린드롬), swap, 최대값 알고리즘 정리
5) 프로젝트
- readme.md 정리
- ERD 설계
- push vs pull 책 추천 한걸로 뉴스피드 방식 정리함.
- aws step function(쿠버네티스같은 오케스트레이션 기술) vs spring batch
- 더블 부킹 어떻게 막을 건지 구상 DB Lock보단 다른 방식을 건의
: springboot의 @Transaction 서비스단 ReservationService 내 validation을 써서 time에 맞지 않는 건 exception 처리해서 막기
📌 멘토링
readme.md로 작업한 거 피드백해주심.
1) 잘못된 표현들 정리
- 클린코드와 성능 최적화에 대한 이야기와 분리
- 베포기술 색션과 중복된 부분이 있다. -> 서버구조도 와 배포 구조로 분리
- 엔티티 다이어그램 도 중복! -> 아예 뺌
2) ERD 설계
-
카테고리, point, 2인실 필드 등 지우는 게 낫다.
핵심 빼고는 안하는 게 나아! -
StudyGroup-Room 관계 다대다인지 일대일인지?
결론 : 연관관계가 없는 걸로 따로따로, 중간에 Reservation이 있기 때문에.
3) API 명세서
- StudyGroup getAll 에서 개별 room에 대한 엔티티 포함해야
room/{roomId}reservation/{reservationId}: @PathVariable 엔티티 식별자 id 넣는 주소로!
4) 스케쥴러
- spring batch -> 리얼타임이 보장되어야 하는지
5) 더블 부팅
- 동시에 할때는 락을 DB에 거는 데 pk(id), 해당 로우에 락을 걸기 때문에 Atomic 보장해줌
validation 문제가 아니니 다른 방법 강구해야
📌 느낀점
멘토님과 <ward-study 프로젝트> 기술면접식으로 질문과 답변이 오갔다. 예상대로 역시나 빡셌다.. 3주차
-
UseCase 정책에 대한 피드백도 너무 왜?라는 한다디에 정확하게 설명 못함. 시무룩해진다.
🤢 예를 들어, 리더는 스터디그룹 3개를 만듦 ? 굳이 왜? -
DB로 더블부킹을 막는 방법에서 내가 생각한 방법이 계속 반려된다. 슬슬 너무 스트레스 강도가 심해진다 느낌.
-
스프링 배치도 반려 리얼타임이 꼭 필요한 기능으로 생각해야되는지도 의문. 하지만 비동기식 MQ 방식으로 괜찮다고 생각함.
📌 해야 할 것
- 코딩 테스트 , 자료구조 알고리즘 - github에 정리
- 멘토님께서 질문하셨던 내용들 블로그 정리
- 김영한 JPA Data 강의 수강
- 대규모 분산시스템 설계 추천책 읽기 : <가상 면접 사례로 배우는 대규모 시스템 설계 기초> 다시 읽기
- 운동 PT - 스트레칭 - 벽에 대고 몸을 트는 행동 20분씩 + 푸쉬업 다시 + 렛풀 다운으로 마무리.
