10장_조수진

10장/10장_조수진.md

@@ -0,0 +1,130 @@
+## 성능이란
+
+### 성능의 지표
+
+- 응답 시간: 데이터를 질의해서 결과를 얻는데 걸리는 시간
+- 처리율: 단위 시간 동안 처리할 수 있는 트랜잭션의 수(TPS)
+
+### 성능 대비를 위한 자원 용량 설정
+
+1. 정점과 한계점
+
+    단순화해서 생각해볼 때, 처리율이 높은 시스템일수록 그에 비례해 필요한 자원의 양도 증가
+
+    동시 실행 수가 증가할 때 여러 자원 중 한 가지라도 한계에 도달하게 되면 성능이 급격히 나빠진다
+
+    → 그 지점을 정점, 한계점
+
+    → 최초에 한계에 이른 자원을 버틀넥 포인트, 병목 지점
+
+    ⇒ 정점을 상정한 자원을 확보하는 것을 사이징(sizing), 캐퍼시티 플랜(capacity planning)
+
+2. 정점 설정을 위한 시스템의 형태 - 주기형과 돌발형
+    - 주기형: 정기적인 사이클을 가지는 형태. 최대치를 예측하기 쉽고 사이징이 가능
+    - 돌발형: 액세스 집중이 언제 발생할지 사전에 예측하기 어려운 형태. ex. 온라인 상거래, 게임
+
+        → 대응하기 위한 한 수단으로 클라우드 기술 사용(Scale up, Scale out)
+
+
+## 데이터베이스와 병목의 관계
+
+데이터베이스는 자주 병목이 된다. 그 이유는,
+
+1. 데이터 양이 아주 많다 = 저장소에 접근이 많다
+2. 스케일 아웃이 어렵다
+    - Shared-nothing만 가능(혹은 리플리케이션이 스케일 아웃 대용으로 사용되기도)
+    - Active-StandBy, Active-Active는 서버를 다중화하는 방법
+
+⇒ 데이터베이스는 튜닝 기술이 중요하고 발달됨
+
+인메모리 데이터베이스
+데이터베이스의 스케일 업을 위한 방안으로, 사용 빈도가 높은 데이터를 메모리에 적재해두어 성능 개선
+
+## 성능을 결정하는 요인
+
+### 데이터베이스 내부 동작 과정
+
+- 파서가 SQL이 문법적으로 잘못된 부분이 없는 지 확인(파스 과정)
+- 옵티마이저가 통계자료를 통해 실혱 계획들을 파악
+- 실행 계획 평가
+- 데이터 액세스
+
+⇒ 옵티마이저, 실행 계획, 통계 자료가 데이터베이스의 성능을 좌우한다
+
+### 통계 자료?
+
+실행계획을 세울 때 참조하는 정보
+
+샘플링한 계산 값이라 완전히 정확하지는 않다
+
+자동 수집되어 구현. 통계 수집을 OFF하거나, 정기 실행을 지정할 수도 있다
+
+- 테이블의 (대강의) 행, 열수
+- 각 열의 데이터 길이, 데이터 형
+- 테이블 크기
+- 열에 대한 기본키, NOT NULL 제약 정보
+- 열 값의 분산과 편향(=Cardinality)
+
+## 실행계획은 어떻게 세워지는가?
+
+### 실행 계획 확인 방법
+
+SQL앞에 `Explain` 키워드를 붙이면 해당 쿼리의 실행 계획을 확인할 수 있다
+
+![Untitled](https://taes-k.github.io/images//posts/2019-11-11-mysql-explain/1.png)
+### Full Scan
+
+전체 테이블을 읽어서 데이터를 읽어오는 경우
+
+실행 계획의 type은 `ALL`
+
+### Range Scan
+
+테이블의 일부 레코드만 읽어서 데이터를 반환하는 경우
+
+Where 절에서 제한한 열이 인덱스로 찾아갈 수 있는 경우 레인지 스캔을 할 수 있다
+
+실행 계획 테이블의 possible_keys, key에서 사용한 인덱스를 확인할 수 있다
+
+실행 계획의 type은 `range` 혹은 `ref`
+
+## 인덱스
+
+데이터베이스 성능 향상 수단으로 가장 일반적인 선택지
+
+- SQL문을 변경하지 않아도 성능 개선 가능
+- 테이블의 데이터에 영향을 주지 않음
+- 일정한 혹은 극적인 효과를 기대할 수 있음
+
+인덱스 확인 SQL `SHOW INDEX FROM 테이블`
+
+인덱스 생성 SQL `CREATE INDEX [인덱스 명] ON [테이블명]([열명])`
+
+### 인덱스의 구조 B-tree
+
+- 트리 형태(Root node, Branch node, Leaf node. 순환 없음)
+- 정렬되어 있다
+- 밸런스(균형)를 유지하고 있다
+- 리프 노드가 연결되어 있다
+
+    → 탐색에 유리하다. 범위 검색에도 빠르게 가능
+
+    → 정렬을 발생하게 하는 처리에서 인덱스가 사용될 수 있다(ex. GROUP BY, 집약 함수, 집합 연산)
+
+    → 삽입, 갱신 시 정렬과 균형이 깨질 수 있음
+
+    → 자동 회복 기능이 있지만 갱신 빈도가 높은 인덱스는 재구성(Rebuild)으로 균형을 되찾는 작업 필요
+
+
+### 인덱스 적용 시 고려해야 할 점
+
+- 데이터 양이 충분히 많을 때 적용하기
+- 기본키, 유일성 제약이 부여된 열에는 불필요
+- Cardinality가 높은 열에 만들 것
+- 인덱스 갱신의 오버헤드 고려하기
+- 인덱스가 너무 많으면 의도한 것과 다른 인덱스가 사용될 수 있음
+- 통계 정보 갱신이 적절히 이루어지도록 하기고려하기
+
+### 참고
+- join_hint, queyr_hint, table_hint를 이용해 옵티마이저 대신 엔드 사용자가 특정 실행계획을 지정할 수 있기는 하다.
+- https://taes-k.github.io/2019/11/11/mysql-explain/