Chapter 09. 데이터베이스 성능

9-1 성능이란
 성능
- 클라이언트 요청에 대한 응답시간(Response Time)과 시간당 처리 할 수 있는 처리량(Throughput)
-

-

 성능의 특성
- 경합부하 구간에서 Response Time이 급격하게 늘어나게 된다
-

 성능 측정 대상
- 목표 TPS 를 산정하고 정해진 응답시간 이내에 모든 요청이 처리되는지 확인해야 함
-

 TPS(Transaction per Second)
- 1초당 처리할 수 있는 트랜잭션의 개수

9-2 데이터베이스와 병목의 관계
 데이터베이스 병목의 원인
- 취급하는 데이터 양이 가장 많다.
- 시스템에서 처리하는 데이터는 영속적으로 보유해야 하는 데이터일 확률이 크다.
- 데이터의 총 크기는 지속적으로 증가한다.
- 동시성을 보장하는 등의 문제로 무조건 적인 자원 증가 통한 성능 문제해결이 어렵다(저장소 확장이 어려움)
- DBMS 내부 I/O 병목으로 인해 대기 시간이 길어 질 수 있다.
-

- DBMS I/O 병목으로 인한 성능 문제를 해결하기 위해서는 절대적인 블록 I/O 를 줄여야 함
- 블록 I/O 를 줄이기 위한 모델 설계 , DBMS 환경 구축 , SQL 튜닝 등의 기술이 발달함

 프로세스 생성 주기
-

- 여러 프로세스가 하나의 CPU를 공유할 수 있지만, 특정 순간에는 하나의 프로세스만 CPU 를 사용하기 때문에 이러한 프로세스 메커니즘이 필연적으로 존재한다.
- interrupted 없이 일하던 프로세스도 디스크에서 데이터를 읽어야할 땐 CPU 를 OS에 반환하고 잠시 수면(waiting) 상태에서 I/O 가 완료되기를 기다린다. 정해진 OS 함수를 호출하고 CPU 를 반환한 채 알림을 설정하고 대기 큐에서 기다림
- 즉 SQL 문에서 발생하는 절대적인 I/O의 횟수를 줄이는 것이 성능 개선의 핵심이다

9-3 성능을 결정하는 요인
 SQL 문의 특성
- SQL은 기본적으로 구조적이고 집합적이고 선언적인 질의 언어다
- 결과 집합을 만드는 과정은 절차적이며, 각각의 프로시저를 만드는 역할을 옵티마이저가 담당한다
-

 SQL(Structured Query Language)
- SQL is designed for a specific purpose : to query data contained in a relational database
 관계형 데이터베이스에 포함된 데이터를 쿼리
- SQL is set based, declarative query language, not an imperative language such as C or BASIC
 선언형 쿼리 언어를 기반

 SQL 문의 실행 과정
-

 옵티마이저
- SQL 옵티마이저는 사용자가 원하는 작업을 가장 효율적으로 수행할 수 있는 최적의 데이터 액세스 경로를 선택해주는 DBMS의 핵심 엔진이다
- 후보군이 될 만한 실행 계획을 찾아낸 후, 통계정보를 이용해 각 실행 계획의 예상 비용을 산정한 후 최저 비용을 나타내는 실행 계획을 선택한다
-

 옵티마이저가 참조하는 통계정보(Statistics)
- 테이블의 데이터를 샘플링 추출하여 통계정보 획득
- 효율적인 참조 데이터 수집
 통계정보가 가지고 있는 데이터
- 테이블의 행수 및 열수
- 각 열의 길이와 데이터형
- 테이블의 크기
- 열에 대한 기본키나 NOT NULL 제약 정보
- 열 값에 대한 통계
- 인덱스에 대한 통계 선택도 , NULL 값의 개수 등
-

9-4 실행계획은 어떻게 세워지는가
 Table Full Scan VS Index Range Scan
-

 인덱스를 이용한 성능 개선
- 인덱스는 큰 테이블에서 소량의 데이터를 검색할 때 사용한다. 대부분의 시스템은 소량의 데이터를 주로 검색하므로 인덱스 튜닝이 무엇보다 중요하다.
- 인덱스 튜닝의 시작은 효율적인 인덱스 컬럼으로 인덱스를 구성하는 것이다.

 인덱스 구조
- 인덱스를 이용하면 데이터 일부만 읽고 멈출 수 있다.
- 범위 스캔이 가능하며, 범위 스캔이 가능한 이유는 인덱스가 정렬된 상태로 저장되어 있기 때문이다.
 인덱스 구조 상세
- 루프와 브랜치 블록에 있는 각 레코드는 하위 블록에 대한 주소 값을 갖는다. 키 값은 하위 블록에 저장된 키 값의 범위를 나타낸다.
- LMC가 가리키는 주소로 찾아간 블록에는 키 값을 가진 첫번째 레코드보다 작거나 같은 레코드가 저장되어 있다.
- 리프 블록에 저장된 각 레코드는 키 값 순으로 정렬되어 있을 뿐만 아니라 테이블 레코드를 가리키는 주소 값 즉 ROWID를 갖는다.
- 인덱스 키 값이 같으면 ROWID 순으로 정렬된다.
- 인덱스를 스캔하는 이유는 검색조건을 만족하는 소량의 데이터를 빨리 찾고 거기서 ROWID를 얻기 위해서다.
- ROWID는 Data Block Address와 Row Number로 구성된다

 ROWID의 구성
-

 인덱스의 특장점
- 인덱스는 데이터베이스의 일반적인 성능 향상 수단이다
- SQL 문을 변경하지 않아도 성능 개선 가능하다
- 테이블 데이터에 영향 주지 않는다. 인덱스는 테이블과 별도의 객체임
- 일정하게 성능을 빠르게 하고 종종 극적인 성능 향상이 될 수도 있다
- 비용 대비 높은 성능향상을 이뤄낸다.
- 특정 SQL 문이 사용하기에 비효율적인 인덱스인 경우 오히려 테이블 풀 스캔보다 느릴 수 있으므로 무조건 적인 사용은 하면 안된다.

 인덱스는 B* Tree의 데이터 구조를 가진다
- 데이터 유지하기 위해 자주 사용하는 구조
- 효율적이고 빠른 탐색 가능
- 데이터를 정렬 Sort 된 상태로 유지
-

 인덱스의 역효과
-

 인덱스 생성 원칙
-

 Table Random Access
- Index Scan을 통해 인덱스 리프 블록에 있는 주소 값을 가지고 테이블을 조회하는 것
- Table Random Access 로 인해 테이블에 있는 내용을 조회할 수 있다.
- Table Random Access 도중 I/O 경합 혹은 이벤트 대기가 발생하므로 성능 상 불리할 수 있다.