0821_retrospecitve

권민아

구매데이터 넣는거하려고 했지만 아직 못했다.
오늘 저녁에 최대한 많이하기가 목표

2023/08/21 - API 수정..

오늘 한 일
1. 백엔드 주간 수업 - 트랜잭션
  - 성능을 향상 하기 위해 생각할 수 있는  방법 -> 인덱스 생성하기, 역정규화 하기
  - 멀티 유저 DB가 된다면 Lock이 필요해짐. 테이블, 레코드, 컬럼, 인덱스 단위의 락을 지원 (레코드 단위 락은 지원은 하는데 실제 물리적으로는 인덱스 락임)
  - 트랜잭션의 성질 : ACID
    - Atomicity: all or nothing
    - Consistency: 트랜잭션 실행 전후 항상 일관된 상태 유지 (항상 제약조건을 만족)
    - Isolation: 한 트랜잭션이 다른 트랜잭션의 영향을 받지 않음
    - Durability: 트랜잭션의 결과가 항상 반영(저장)되어야 함
  - 분산 시스템 관련 이론 : CAP
  - optimistic concurrency control vs. pessimistic lock
    - 낙관적 락: 항상 충돌이 없을 것이라 생각 (잠금 X)
    - 비관적 락: 항상 충돌이 있을 것이라 생각 (잠금 O)
  - serial schedule: 트랜잭션을 항상 한번에 하나씩만 수행하는 것
    - 모든 트랜잭션을 serializable하게 수행하면 성능이 감소 -> isolation level을 조정
  - 각 isolation level 마다 발생할 수 있는 문제
    1. Read Uncommitted : Dirty Read Problem
    2. Read Committed : Non-repeatable Read Problem
    3. Repeatable Read : Phantom Read Problem
    4. Serializable
    - MySQL은 Repeatable read가 기본 값이지만 mvcc를 사용해 phantom read 문제가 발생하지 않음
2. 더미 데이터 생성
  - 드디어 더미 데이터 만들기.. 파이썬으로 더미 데이터를 담은 csv 파일을 만든 후 scp로 mysql이 있는 ec2에 전송하고 파일을 읽어서 테이블에 넣었다.
3. API 수정
  - 프론트 요청사항을 반영해 API 응답 형태를 수정했다. 덕분에 쿼리를 수정하는데 jpa에서 여러 개의 일대다 관계를 fetch join할 수 없다며 오류가 났다. batch size를 설정해서 이 단위로 fetch하도록 수정해 해결했다.

아쉬운점
1. API 명세서 꼼꼼하게 작성하기
  - 자꾸 수정사항이 생기는 게 초반에 API 명세서를 꼼꼼하고 확실하게 작성하지 않고 개발해서 그런 것 같다. 조금 더 프론트엔드와 안드로이드 분들과 소통하면서 API를 만들었어야 했는데 아쉬움이 많이 남는다..
2. 기록 잊지 말기
  - 글 쓰는 건 항상 귀찮다. 귀찮아서 미루다가 이제는 시간이 부족해서 잘 못 쓰겠다. 항상 글로 정리하는 습관을 들여야 하는데 잘 안되는 것 같아 아쉽다.

한마디
오늘 일정이 끝난 후 304호에서 백엔드 프론트엔드 분들과 같이 공부해서 즐거웠다. 이제 매일 얼굴을 마주하는 날도 얼마 남지 않았다는 사실이 슬프다..🥲

김유빈

*TODAY
- 브랜치 머지
- 코드리뷰
- 완료 화면 api연동
- 로딩화면 계획
- 옵션 api수정

박세영

해야 할 일 
색상 api연동, ux개선
360도 머리아파..

스핀 이미지가 안끊기게 하려면 이미지를 미리 받아와서 캐싱을 해야하는데 캐싱이 왜 안되는걸까
request log는 바로 찍히는데 실제 이미지를 다 받아오는데는 오래 걸리나보다 
이미지를 다 받아오는건 어떻게 확인해야 할까? 
코일 내부 코드를 조금 더 뒤져 봐야겠다 ..

엄석훈

오늘은 API 연동을 다 끝냈다. 그리고 추천 설문 페이지의 아주 간단하게라도 리팩토링을 다 끝냈다. 확실히 초반에 구조를 잘 잡아서 컴포넌트를 만들었더니 편한 것 같다. 다만 후반으로 갈수록 우선은 돌아가게 하기 위해서 함수를 막무가네로 작성하고 있는데 나중에 시간나면 고쳐보도록 해야겠다. 내일은 이제 옵션 페이지를 완벽하게 돌아가도록 마무리 하고 수요일부터는 최적화나 새로운 기술적 도전을 해봐야겠다.

이승현

색상 api하는중
최대한 오늘 연동
어제 색상 API가 드디어 나와서 어제부터 부랴부랴 연결을 시작했다. 사실 가장 구현하기 어려운 부분일 것 같았는데 연결하다보니 역시나였다. 오류가 많이 나고 구조가 복잡해서 코드가 굉장히 더러워졌다. 코드를 괴롭히면서 작성하고 있는데 코드한테 미안하다.
그래도 일단 돌아가는 쓰레기라도 만들어야겠다는 일념 하에 작업을 하고 있는데 내일까지 색상 API 연동을 완료하는 것이 현재 목표다. 너무 힘들다 ㅠ ㅠ
이제 일주일 정도 남았는데 열심히 달려야겠다. 주말에 진짜 열심히 했는데 생각보다 진도가 많이 나가지 않아서 슬펐다. 흑흑 , , , , 내일도 화이팅 , , ,
역시 애니메이션 중첩 문제도 어렵고, props 넘기는 것도 어렵고,
사실 context로 모든걸 관리하고 싶은데 부하가 심할 것 같아 어느정도 선에서만 관리하고 있는데 나중에 시간나면 성능차이도 계산해보고 싶다.

최규현

### <호눅스님 강의>

- ACID에서 Consistency?
    - 트랜잭션 전후로 *제약조건*이 일관성을 가져야 한다!
- 분산 시스템의 CAP 이론
    - Consistency ⇒ 분산된 어느 서버에 요청하더라도 같은 요청에 대해 동일한 결과를 받을 수 있어야 함
    - Availability
    - Partition Tolerence
    - 3개 모두 만족시킬 순 없고 Consistency를 포기함. But Eventual consistency(곧 일관성이 맞춰질 상태)는 만족해야 함
- NoSQL의 특징
    - 그다지 기억할 필요는 없음
    - Basically Available
    - Soft State
    - Eventual Consistency
- 개발자들은 말장난을 좋아함
- Serial Schedule
    - 한 번에 하나씩의 트랜잭션만 실행
    - A, B, C 트랜잭션이 있을 때 가능한 결과들의 집합 ⇒ 3!보다 작거나 같음 (덧셈 관련 트랜잭션이면 결과가 1)
    - 트랜잭션 결과가 Serial Schedule의 부분집합인 경우 Serializable이라고 함
- 스프링에서의 낙관적 잠금이 무엇인가?
    - 면접에서 물어볼 수 있음
    - Lock 없이 트랜잭션이 가능할까?
    - 일단 lock 안걸고 conflict 발생하면 다시 transaction 실행함
- Transaction에서 동시성 문제
    - Non-repeatable
        - 같은 값을 두 번 읽었을 때 발생하는 문제
        - 다른 트랜잭션에서 삽입 혹은 삭제가 원인
    - Phantom Read
        - 다른 트랜잭션에서 수정이 원인
    - MySQL은 Repeatable Read가 default level인데 phantom read가 innoDB 자체적으로 MVCC에 의해 발생하지 않음
    - start transaction, start transaction_isolation ~, commit 등 명령어로 직접 실습 진행함
    - transaction마다 사본을 만듦

### <오늘 한 일>

- 카마스터 설문 및 카마스터 추천 옵션 더미 데이터 1만개 생성 (by python and bulk insert)
- 카마스터 설문 조회 API 및 카마스터 설문 저장 API 개발
- 카마스터 설문 기반 차량 추천 API 개발 계획 수립
- 스프링으로 PDF, 메일 발송 구현 방법 학습