Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[10주차] 심규창 학습 PR 제출합니다. #57

Open
wants to merge 28 commits into
base: main
Choose a base branch
from
Open
Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
28 commits
Select commit Hold shift + click to select a range
94acf9e
[3주차] 심규창 학습 PR
gyuchangShim Oct 10, 2023
81f51eb
[3주차] 심규창 학습PR 수정
gyuchangShim Oct 10, 2023
28bdd0a
Merge branch 'COW-edu:main' into main
gyuchangShim Oct 14, 2023
824bf2f
[4주차] 심규창 학습 PR
gyuchangShim Oct 17, 2023
748e3b8
Update 4주차.md
gyuchangShim Oct 17, 2023
e12a9cd
Update 4주차.md
gyuchangShim Oct 17, 2023
c1b6259
Update 4주차.md
gyuchangShim Oct 17, 2023
c4771ae
Rename week04/4주차.md to 심규창.md
gyuchangShim Oct 17, 2023
0b504dd
Refactor: 이미지 누락으로 패키지에 이미지 추가
gyuchangShim Oct 17, 2023
0f9bdb2
[4주차] 심규창 학습 PR 제출합니다.
gyuchangShim Oct 17, 2023
65877a7
[4주차] 심규창 학습 PR 제출합니다.
gyuchangShim Oct 17, 2023
a26c21a
Merge branch 'COW-edu:main' into main
gyuchangShim Nov 3, 2023
9b4d8a4
[7주차] 심규창 학습 PR 제출합니다.
gyuchangShim Nov 7, 2023
1ebc6ed
Fix: PR 과제 이름 수정
gyuchangShim Nov 7, 2023
e950fa9
Merge branch 'COW-edu:main' into main
gyuchangShim Nov 12, 2023
a6a2b97
[8주차] 심규창 학습 PR 제출합니다.
gyuchangShim Nov 13, 2023
89f7130
Fix: 이미지 경로 수정
gyuchangShim Nov 13, 2023
39bba17
Fix: 오타 및 이미지 순서 수정
gyuchangShim Nov 13, 2023
a7d9f2c
Feat: postman API 링크 추가
gyuchangShim Nov 13, 2023
7fc4dfc
Update 심규창.md
gyuchangShim Nov 15, 2023
75843cc
Update 심규창.md
gyuchangShim Nov 15, 2023
fd0cdb0
Merge branch 'COW-edu:main' into main
gyuchangShim Nov 19, 2023
9168c42
[9주차] 심규창 학습PR 제출합니다.
gyuchangShim Nov 20, 2023
eebb5bb
Merge branch 'COW-edu:main' into main
gyuchangShim Nov 24, 2023
5d031ec
[10주차] 심규창 학습PR 제출합니다.
gyuchangShim Nov 26, 2023
7e35f9f
Feat: 이미지 추가
gyuchangShim Nov 26, 2023
0d18035
feat: dataset setup
gyuchangShim Mar 28, 2024
22989f0
Delete custom_dataset_yolo_nas.ipynb
gyuchangShim Mar 28, 2024
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
18 changes: 0 additions & 18 deletions week10/10주차.md

This file was deleted.

106 changes: 106 additions & 0 deletions week10/심규창.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,106 @@
# 10주차 학습 PR

이번 주는 살짝 쉬어가는 느낌으로 실습 PR은 별도로 없고,
H2 Database를 설치해오시면 좋을 것 같습니다!

## Indexing이란?
(clustering index, secondary index)
> Index: DB에서 수많은 데이터에 대해 검색 속도를 향상시켜 주기 위한 목차의 개념
> Data Block: DB에서 데이터를 저장하는 가장 작은 단위의 개념

> - Index가 없는 상태에서 많은 데이터에 대한 조회가 필요하다면 하나하나 비교해서 데이터를 찾아야 하기 때문에 속도가 굉장히 느리다.
> 이를 보완하기 위해 각 데이터에 Index를 매겨 데이터 검색 등의 작업 속도를 빠르게 할 수 있다. Index는 데이터와 별개로 저장되기 때문에
> Index를 통해 더 많은 데이터를 조회할 수 있다.
> - Index를 사용하면 속도는 빨라지지만 Index의 순서가 섞인다면 데이터 추가 등의 작업에서 문제가 발생할 수 있다. 이러한 Indexing 방법은
> 크게 Clustering Index, Secondary Index로 구분된다.
>> 1. Clustering Index: DB 안에서 PK를 지정하는 경우 Clustering Index
>> (1) 테이블에서 1개만 존재한다.
>> (2) 데이터가 정렬된 상태로 저장된다.
>> (3) index는 Data Block의 첫 번째 record의 주소를 갖는다.
>> 1. index를 통해 Data Block에 접근 가능하기 때문에 Secondary Index 보다 빠르다.
>> 2. Secondary Index: PK 이외에 정렬 기준이 있는 경우 Secondary Index
>> (1) 테이블에서 여러개 존재할 수 있다.
>> (2) 데이터가 정렬되지 않은 상태로 저장된다.
>> (3) index가 모든 데이터 record의 주소를 알아야 한다.
------------------------
## DB의 Relationship(1:1, 1:m, n:m)
> Relationship: DB 안에서 Data(Table, Entity 등)들이 서로 연관된 상태
> 1. 정의에 따른 관계: 각각의 Data를 정의하는 데 연관성이 필요한 경우
> 2. 동작에 따른 관계: 하나의 Data가 다른 Data(동작)를 행하는 경우
>
> 관계 차수: Relationship에 참여하는 Data의 개수(1:1 / 1:N / N:M)

> DB에서의 관계는 1:1, 1:n, 1:m으로 나타낼 수 있다. 각각 DB Table이 연결을 갖는 개수를 나타내는 데 모든 Table은
> 여러 Table을 참조할 수 있고 참조 당할 수 있다. 또한 Table 안에서의 PK가 다른 Table을 참조하기 위한 FK가 될 수 있다.
-------------------------
## JPA 엔티티의 생명 주기
![jpa entity lifecycle](https://github.com/COW-edu/COW-Spring-2/assets/132640569/7ae38480-fd21-4c13-9124-288ba8adfdf3)
> 영속 상태와 비영속 상태: 영속성 Context에서 관리되는 지에 대한 여부
> 준영속 상태: 영속성 Context에 저장되어 있다가 분리된 상태(영속 상태에서의 변경 감지 등 불가)

> JPA Entity는 비영속, 준영속, 영속 상태를 갖는다. 처음 객체가 생성되었을 때는 영속성 Context에 저장되지 않기 때문에
> 비영속 상태를 갖는다. 이후 EntityManager를 통해 Entity를 영속 Context에 저장하게 되면 영속 상태로 변한다. detach를 통해
> 영속 상태의 Entity를 준영속 상태로 바꿀 수 있는데 이때 영속 상태일 때의 1차 캐시나 쓰기 지연 저장소에 저장된 Query 등이 삭제된다.
> 준영속 상태의 Entity는 병합(merge)을 통해 다시 영속 상태로 변환할 수 있다.

## @Id, @GeneratedValue
> @Id: Entity의 속성이 PK임을 지정하는 어노테이션
> @GeneratedValue: Entity의 PK를 자동으로 생성해주는 어노테이션
> (1) Auto: DB에 따라 아래 3개의 방법 중 하나를 선택하는 방법
> (2) Identity: DB에 PK 지정을 위임하는 방법(DB에 의존적인 성격 - H2, MySQL, SQL Server 등에 사용)
> (3) Sequence: DB Sequence를 사용해 PK를 지정하는 방법(DB에 의존적인 성격 - H2, DB2, Oracle 등에 사용)
> (4) Table: DB Table을 사용해 PK를 지정하는 방법(모든 DB에서 적용 가능)
-----
# 9주차 세션 정리(추가 과제)

## DB 트랜잭션이란?
> DB Transaction은 DB의 상태를 변화시키는 최소한의 작업 단위이다. DB에서 상태가 변하는 것은
> Query를 통해 데이터를 저장, 조회, 수정, 삭제하는 등의 작업을 의미한다. Transaction은 개발자가 정하는
> 단위로 하나의 로직을 처리하기 위해 여러 Query를 작성할 때, 작성된 모든 Query가 성공적으로 완료되면 하나의 Transaction으로 정의한다.

> 또한 DB Transaction은 다음과 같은 특징을 가진다.
>> 1. 원자성: Transaction은 모두 반영되거나 반영되지 않는 경우만 존재한다.
>> 2. 일관성: Transaction의 처리 결과는 일관적이어야 한다.
>> 3. 독립성: 각각의 Transaction은 서로에게 영향을 줄 수 없다.
>> 4. 지속성: Transaction이 성공적으로 끝나면 처리에 대한 결과는 영구적으로 저장된다.

> 하나의 Transaction은 Commit or Rollback의 결과를 갖는다.
> Transaction에 대한 처리가 성공적으로 완료되고 일관성을 가질 때는 Commit, 처리 도중 비정상적으로
> 완료되어 원자성이 깨진 경우 Rollback 결과를 갖는다. Rollback의 경우 Transaction의 시작 지점으로 돌아간다.
-------------------------
## JPA의 1차 캐시, 2차 캐시
> 캐시는 반복해서 사용되는 데이터에 대해 빠르게 사용할 수 있는 방법이다. 일반적으로 데이터는 DB에서 받아오지만 DB 접근 시간이
> 오래 걸리거나 반복적으로 동일한 결과를 반환하는 경우에는 캐시를 사용하는 것이 더 효율적이다. 이렇게 캐시 영역에서 데이터를 받아오는 과정을
> 캐싱이라 한다. Spring에서의 캐시는 영속성 Context를 통해 사용 가능하다.
>>Spring에서 같은 데이터를 대상으로 같은 동작을 반복적으로 요청할 경우 실제 쿼리는 하나의 쿼리만이 실행된다. 그 이유는 Spring에서는
> 첫 쿼리에 대한 결과를 1차 캐시에 저장하고 같은 요청이 들어올 때 재사용하기 때문이다. 하지만 1차 캐시는 Transaction 내에서만 동작하며 영속성
> Context가 종료되면 저장된 데이터도 소멸한다.
>
>> Spring의 2차 캐시는 Application 범위에서 동작한다. 1차 캐시와 다르게 Application이 종료될때까지 유지되고 저장한 데이터를 복사해
> 복사본 데이터를 반환한다. 하지만 Application 전체 대상이기 때문에 여러 스레드가 동시에 값을 사용할 때 동시성에 대한 문제가 발생할 수 있다.

![caching](https://github.com/COW-edu/COW-Spring-2/assets/132640569/99ab34b9-62d7-4daa-82ad-b62753652fe8)
> - 캐싱 동작 방식
>1. 최초 쿼리 동작 시 데이터 반환
>2. 쿼리 동작에 대해 1차 캐시가 존재한다면 1차 캐시의 결과 반환
>3. 1차 캐시에 데이터가 없지만 2차 캐시에 존재하는 경우 2차 캐시에서 반환
----------------
## JPA의 변경 감지
> 영속성 Entity: 영속성 Context에 속한 Entity
> 스냅샷: DB의 데이터가 영속성 Context에 저장될 때의 정보(Entity 영속화의 최초 정보)
> Flush: 영속성 Context의 변경 내용을 DB에 반영하는 과정(영속성 Context와 DB의 상태를 맞추는 것)

> 변경 감지는 Transaction Commit시 영속성 Entity에 대해 update해주는 기능이다.
> Transaction Commit이 일어날 때 스냅샷과 바뀐 Entity를 비교해 update한다. Spring에서는 @Transactional 어노테이션을 통해
> 메서드를 묶고 해당 메서드가 종료될 때 Transaction Commit이 발생한다.(이때 Flush도 자동으로 작동)
> - 변경 감지의 대상은 영속성 Entity이지만 준영속 Entity도 변경 감지가 가능하다. Entity의 모든 속성에 대한 변경 감지는 병합(merge), Entity의 속성에 대한
> 부분 수정은 Dirty Checking 방식이 있다.
>> 1. Dirty Checking: Service 계층에서 update 메서드를 추가해 데이터를 수정하는 방식(필요한 속성만 수정)
>> 2. 병합(Merge): em.merge(Entity) 메서드를 통해 영속 Entity의 값을 파라미터로 전달받은 준영속 Entity의 값으로 수정하고 영속성 Entity를 반환해 저장하는 방식(Entity의 모든 속성 필요)
----------------
## JPA의 쓰기 지연
> Transaction에서 생기는 모든 쿼리는 쓰기 지연 저장소에 쿼리가 저장된다. 저장된 쿼리는 Transaction Commit 시점에
> DB로 전달되는 데 이를 통해 하나의 Transaction이 DB에 접근하는 시간이 감소하는 이점을 얻는다. 일반적으로 쿼리를 생성하면
> 바로 DB에 전달되지만 이 과정은 DB와의 연결 ~ 해제 과정이 반복되기 때문에 쓰기 지연 저장소를 통해 보다 효율적으로 DB에 접근할 수 있다.

>