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

taehyun (20230924): 데이터베이스 첫걸음 9-10장 #28

Open
wants to merge 1 commit into
base: main
Choose a base branch
from
Open
Changes from all commits
Commits
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
71 changes: 71 additions & 0 deletions Document/2023/0924/taehyun/README.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,71 @@
# 디비 디비 딥(DB DB Deep) 스터디 2회차

## [ 데이터베이스 첫걸음 ] 9장 백업과 복구 - 장애에 대비하는 구조

## [ 데이터베이스 첫걸음 ] 10장 부록_성능을 생각하자 - 성능 향상을 위해

### 성능이란

#### 성능을 측정하는 2가지 지표

시스템 세계에서 성능은 2가지의 지표(Matrix)에 의해 측정된다.

1. 처리 시간(Processing Time) 또는 응답 시간(Response Time)
2. 처리율(Throughput)

이때 처리율에서 가장 중요한 점은 1초당 또는 1시간당처럼 단위 시간 지표다. 단위 시간이 없으면 성능 지표로서 활용할 수 없다. 예를 들어 150만 명이 이용하고 있는 서비스가 있을 경우 10년 단위로 150만 명이 이용할 수 있고, 1만 명이 이용하고 있는 서비스가 있을 경우 1초당 1만 명이 이용할 수 있기 때문이다. 따라서 단순히 절대적인 수치만을 가지고는 성능 지표로 활용할 수 없다.

시스템에서는 보통 특정 처리(Transaction)를 1초 당 몇 건 처리할 수 있는지 나타내는 TPS(Transaction Per Second)를 처리율로 사용한다. 이외에 웹 페이지를 1초당 몇 회 열람했는지를 나타내는 지표인 PV/S(Page View/Second)도 있다.

#### 장점과 한계점

처리율이 성능에서 중요한 이유는 시스템의 자원 용량(Resource Capacity)을 결정하는 요인이기 때문이다. 처리율이 높은 시스템일수록 CPU나 메모리 같은 하드웨어 자원이 매우 필요하다는 것을 의미한다. 따라서 하나의 처리를 위해서 시스템은 자원을 소비하며, 동시이 실행하는 사용자 수가 많아질 수록 그만큼 필요한 물리 자원도 증가한다는 의미가 된다.

그 결과 특정 자원이 한계에 이른 시점이 찾아오면 급격하게 성능이 나빠지기 시작하며, 이때 최초로 한계에 이른 자원을 병목(Bottleneck Point)이라 한다. 즉, 병목에 의해 응답 시간은 상승하고 처리율은 떨어지는 것이다.

이것은 동시에 실행되는 처리가 가장 많아지는 순간을 설정해서 자원을 준비해 두지 않으면, 정점(Peak)일 때 극단적인 지연을 일으키게 된다는 것을 의미하며 이때의 처리량을 한계점(Breaking Point)이라 부른다. 정점을 상정하여 자원을 확보해 두는 것을 사이징(Sizing) 또는 가용량 계획(Capacity Planning)이라 한다. 이는 시스템의 요건 정의 단계에서 핵심이 된다.

#### 주기형과 돌발형

정점이 아닐 때 필요한 자원량과 정점일 때 필요한 자원량에 커다란 차이가 있어 정점에 맞춘 자원을 준비하면 역으로 평상시에는 자원이 낭비되는 문제가 발생한다. 이런 돌발형 액세스 집중에 대응하는 수단 중 대표적인 것이 바로 클라우드(Cloud)다. 클라우드는 가상화(Virtualization)를 기반으로 자원량을 유연하게 변동할 수 있는 기술로, 자원의 성능을 더 좋은 것으로 바꾸는 방식인 수직적 확장(Scale Up)과 자원의 수를 늘리는 방식인 수평적(Sclae Out) 모두 쉽고 빠르게 도입할 수 있는 장점이 있따. 따라서 정점인 상황과 아닌 상황에 유연한 대응이 가능해져 효율적인 자원 및 비용 관리가 가능해진다.

단적인 예로 비엔엑스(beNX)의 글로벌 팬덤 라이프 플랫폼 위버스에서는 방탄소년단(BTS)의 게시글이 올라올 때면 일순간 트래픽이 폭발적으로 증가하였고, 이를 해결한 과정을 [전 세계 팬들이 모일 수 있는 플랫폼 만들기](https://youtu.be/X2I4NuTOWS8?t=170)라는 제목으로 AWS Community Day 2020에서 공유하기도 하였다.


### 데이터베이스와 병목의 관계

#### 데이터베이스는 왜 병목이 되는가

데이터베이스는 시스템에서 가장 병목이 되기 쉬운 부분이다.

먼저 데이터베이스는 시스템에서 처리하는 데이터 전체를 일괄로 보관하는 장소로, 그 총량은 계속해서 증가하고 있기 때문이다. 다시 말해 시스템에서 데이터의 양이 가장 많은 부분이 데이터베이스가 된다는 의미다.

다음으로 자원 증가를 통한 해결이 어렵다. 데이터베이스의 명목 지점은 CPU 또는 메모리가 아닌 저장소, 다시 말해 하드 디스크에 해당한다. 기본적으로 저장소는 수평적 확장이 어려운 자원으로, 데이터베이스가 기본적으로 Active-Standy 구성이나 공유 디스크를 바탕으로한 Active-Active 구성을 사용할 수밖에 없기 때문이다.

### 성능을 결정하는 요인

#### 구문 오류가 없는지를 보는 파스

#### 실행계획과 옵티마이저

#### 옵티마이저에 실행계획을 맡기는 이유

#### 옵티마이저가 참조하는 통계정보

옵티마이저가 실행 계획을 세울 때 옵티마이저에 중요한 정보를 제공하는 것이 바로 카탈로그 매니저(Catalog Manager)다. 여기서 카탈로그란 DBMS의 내부 정보를 모아놓은 테이블로, 테이블 또는 인덱스의 통계정보가 저장되어 있다. 이는 간단하게 통계정보(Statistics)라고 부르기도 한다. 따라서 통계정보가 부족한 경우 옵티마이저가 최적의 실행계획을 선택할 수 없는 상황이 발생하기도 한다. 대표적인 예로 테이블에 데이터 삽입, 갱신, 그리고 제거 작업이 수행되었는데 통계정보가 갱신되지 않는다면 옵티마이저는 결국 과거의 정보를 바탕으로 실행 계획을 세우기 때문에 잘못된 계획을 세울 수밖에 없다. 이를 위해 특정 DBMS의 경우 쿼리를 실행할 때 통계정보를 실시간으로 수집하는 기능을 갖춘 경우도 있다. 이를 JIT(Just In Time) 통계라고 부르며, 항상 통계정보를 최신화, 다시 말해 실제 테이블 및 인덱스의 통계정보와 동기화할 수 있다는 장점이 있지만 그만큼 지연을 발생시키는 병목이 될 수 있다는 단점도 존재한다.

이때 저장되는 정보는 보통 아래와 같다.

1. 각 테이블의 대략적인 레코드수
2. 각 테이블의 대략적인 필드 수와 필드의 자료형, 그리고 필드의 크기
3. 필드의 카디널리티(Cardinality)
4. 테이블의 크기
5. 필드에 대한 기본키 설정과 `NOT NULL` 제약의 정보
6. 필드 값의 히스토그램(분산과 편향)
7. 인덱스 정보

여기서 카디널리티란 필드 내의 고유한 값의 개수를 의미하며 카디널리티가 높을 수록 해당 열의 값이 중복되지 않게 존재한다는 걸 의미한다.


### 실행계획은 어떻게 세워지는가