[ 서버 사이드 프로젝트 챌린지 ] 23.03.11

https://github.com/mooh2jj/side-project-challenge-study/tree/main/%EA%B9%80%EB%AC%B4%EA%B1%B4/week1

GitHub - mooh2jj/side-project-challenge-study: 서버 사이드 프로젝트 챌린지 스터디입니다.

1) git-flow 란 무엇인지 정리
2) git 대표적 명령어 정리

3) MySQL에서 DB 테이블 설계시 중요 요소 각 정리

챌린지) 각 개별로 드립니다. 

1. Git - flow란 무엇인지 정리

- 협업에는 크게 3가지 구성이 있다.
1. Fork 와 Pull Request 를 사용하는 방법
2. Organization 과 branch 를 사용하는 방법
3. Organization 과 단일 브랜치를 사용하는 방법

1번 방법은 다수의 repo가 생성된다는 단점이 있다.
2번 방식은 master브랜치가 항상 완전한 기능을 갖춰야하는 경우에 사용한다.
3번 방식은 동일한 repo를 작업을 하면 다른 사람이 원격 저장소로 올린 커밋을 로컬에 반영하지 못한 경우가 있다.
이 경우에 pull을 하면 머지 커밋이 생성되어 git log의 지옥이 시작이 된다. 그래서 보통은 rebase를 사용하여 이 문제를 해결한다.

- Git Flow는 5가지의 브랜치를 무조건 사용x
- 각 프로젝트 및 조직에 적합한 규칙에 따라서 O

 

2. Git 명령어 정리

git init: Git 저장소를 초기화합니다.
git clone: 원격 저장소를 복제합니다.
git add: 변경된 파일을 스테이지에 추가합니다.
git commit: 스테이지에 있는 파일들을 커밋합니다.
git push: 로컬 저장소의 변경 내용을 원격 저장소로 전송합니다.
git pull: 원격 저장소의 변경 내용을 로컬 저장소로 가져옵니다.
git status: 현재 저장소의 상태를 확인합니다.
git log: 커밋 내역을 확인합니다.
git branch: 브랜치를 생성하거나 확인합니다.
git checkout: 브랜치를 변경하거나 특정 커밋으로 이동합니다.

 

3. MySQL에서 DB 테이블 설계 중요 요소 정리

1. 데이터 타입 : MySQL은 많은 데이터 타입을 제공한다. 이때 필드에 적절한 데이터 타입을 선택 -> 정확성 성능 향상

2. 인덱스 :  인덱스는 테이블에서 데이터를 빠르게 검색할 수 있도록 해주는 중요한 요소
   https://pos04167.tistory.com/118

3. 정규화
- 정규화 : 데이터의 중복 데이터와 이상 현상을 제거하여 데이터의 일관성 , 성능 향상을 목표

1차 정규형(1NF): 모든 필드가 원자 값(Atomic Value)을 가지며, 중복되는 데이터가 없어야 합니다.
2차 정규형(2NF): 1차 정규형을 만족하면서 기본 키가 아닌 모든 필드가 기본 키에 대해 완전 함수적 종속( Fully functional dependency)을 만족해야 합니다.
3차 정규화(3nf) : 비주요 열 간에 의존성이 없어야 합니다.

4. 제약 조건 : 제약 조건을 이용해서 데이터 무결성을 보장한다. ->pk , fk , not null ...

5. 식별 비식별 관계를 생각
- 식별 : 부모 테이블의 PK가 자식 테이블의 FK로 사용 - 보통  1:1/1:N
  - 이걸 보면 자식 테이블에는 부모 PK가 복합키로 사용이 된다.
  - 그러면 이런 생각이 생긴다? 복합키는 인덱스를 어떻게 타지??
    - 이때 복합키는 인덱스를 타는 방식은 단일 열 기본 키와 유사한데 각 열의 값에 대한 인덱스 열을 생성하여 복합 인덱스를 구성한다.
    

- 비식별 : 부모 테이블의 PK가 자식 테이블의 일반 열로 들어가는 경우 : N:M

 

4. 개인 과제 (MySQL에서 최적화를 위한 설정 / 인덱스에서 자료 구조 관점에서 장단점 조사)

1. 버퍼 풀 크기 설정 : innodb_buffer_pool_size
버퍼 풀 크기는 MySQL이 데이터를 메모리에 캐싱하는 크기입니다. 
이 값을 적절히 설정하면 디스크 I/O를 줄이고 쿼리 성능을 향상시킬 수 있습니다. 

버퍼 풀은 DBMS가 할당한 메모리 공간에서 구성되며, 읽어온 데이터는 버퍼 풀에 저장됩니다. 이후, 같은 데이터가 다시 필요한 경우에는 디스크에서 읽어오지 않고 버퍼 풀에서 빠르게 데이터를 읽어와서 처리합니다.

- 예를 들어 SELECT 쿼리를 실행을 하게 되면
   1. 쿼리 입력 값에 대한 해시 값을 생성
   2. 키에 해시 값 / 값에 쿼리의 결과 값을 저장하게 된다.
   3. 캐시에서 결과 값을 찾을 수 없으면 디스크에서 데이터를 읽어온다.


2. 쿼리 캐시 크기 설정 : query_cache_size
쿼리 캐시 크기는 쿼리 결과를 캐싱하는 크기입니다. 
쿼리 결과를 캐싱하면 동일한 쿼리를 실행할 때 빠르게 결과를 반환할 수 있으므로 쿼리 성능이 향상됩니다. 
하지만 쿼리 캐시 크기를 너무 크게 설정하면 메모리 부족으로 인한 성능 저하가 발생할 수 있으므로 적절한 값을 설정해야 합니다.

3. 로그 레벨 설정 : log_error_verbosity
로그 레벨을 높여서 디버깅을 할 때 유용합니다. 로그 레벨을 높이면 MySQL에서 발생하는 오류 및 경고 메시지를 더 자세하게 확인할 수 있습니다.

4. 인덱스 설정 : index_merge
인덱스 설정은 데이터베이스에서 데이터를 빠르게 검색하는 데 매우 중요합니다. 
MySQL에서는 인덱스를 이용해 데이터를 검색하는데, 여러 개의 인덱스를 사용할 때 index_merge 옵션을 활성화하면 더욱 빠르게 데이터를 검색할 수 있습니다.

- index_merge 옵션??
여러 개의 인덱스를 조합해 데이터를 검색하는 옵션이다.

```sql
SELECT * FROM table_name
WHERE column1 = 'value1'
AND column2 = 'value2'
```
위에 쿼리를 살펴보면 만약에 각각의 조건에 인덱스 1,2가 존재한다면 index_merge 옵션을 사용하여
각각의 조건에 해당하는 레코드를 검색하는 것보다 빠르게 데이터를 검색할 수 있다.

5. 쓰기 작업의 지연 설정 : innodb_flush_log_at_trx_commit
   1. 트랜잭션 커밋 시 디스크에 저장 x , 버퍼 풀에 데이터 유지 -> 가장 빠르지만 시스템이 꺼지면 버퍼 풀이 날라가서 위험
   2. 커밋 시마다 디스크에 데이터 저장 : 데이터 일관성이 좋다. 하지만 성능이 떨어진다.
   3. 커밋 시 디스크에 데이터 기록 x , 버퍼 풀에 데이터를 유지하지만 1초마다 디스크에 기록 : 일관성 , 성능을 다 고려

- 기본적으로 2 방식을 사용한다. 0,2를 설정하여 성능을 높일 수 있다.

# 자료구조 관점에서 알아보자
1. MySQL은 기본적으로 B-Tree를 사용한다. 이 구조는 이진트리와 비슷하지만 다르다.
여기서 B는 바이너리가 아닌 Balance를 의미 

- B-Tree란
바이너리 서치 트리에서 발전되어 모든 리프노드들이 같은 레벨을 가질 수 있도록 자동으로 균형을 맞추는 트리
이진트리와 다르게 하나의 노드에 많은 트리를 가지고 있다.

여기서 탐색의 과정을 살펴보면
1. 루트 노드에서 시작으로 하양식으로 key 검색을 수행 한다.
   - 만약에 k와 같은 키를 찾으면 탐색 종료
   - 검색하는 값들과 key들의 대소관계를 비교하며 어떠한 key 사이에 k가 존재한다면 자식 노드로 진행

2. 해당 과정은 리프 노드에 도달할 때까지 반복
3. 만약에 리프 노드에 k가 없으면 검색 실패

### 분할과 병합
- 분할은 리프 노드에 삽입을 하였을 때 새로운 키 값이 해당 리프 노드에 이미 존재하면 삽입 연산이 실패한다.
- 이때 b-tree는 리프 노드를 분할하여 새로운 키 값을 저장할 공간을 확보
- 노드가 움직이는 것이 아니라 새로운 리프 노드를 생성

- 병합은 삭제 연산을 할 때 키 값이 저장된 노드가 리프 노드인 경우 해당 노드를 삭제하고
- 리프 노드의 수를 줄인다. 이 때 인접한 노드를 합쳐서 하나의 노드로 만든다.