[SQLP] 이론 8. 데이터베이스 성능

1. 성능

 - 클라이언트 요청에 대한 응답시간과 시간당 처리할 수 있는 처리량

   (Response Time, Throughput)

 

2. 용어

 - Concurrent User : 동시 사용자 (Active + Inactive User)

 - Active User : 대상 서버에 부하를 발생시키고 있는 사용자

 - Inactive User : 현재 서버에 요청을 보내고 있지 않은 사용자

 - TPS (Transaction Per Second) : 서버가 일정 시간(초) 내에 처리한 트랜잭션의 양

 - Response Time : 요청 후 응답을 받을 때 까지 소요된 시간

 - Resource : 한정되어 있는 자원

 

3. 특성

 - 경합부하 구간에서 Response Time 이 급격하게 늘어남

 

4. 성능 측정 대상

 - 목표 TPS 산정 후 정해진 응답시간 내에 모든 요청이 처리되는지 확인

 

5. 병목현상의 원인

    - 데이터의 양이 많음

    - 데이터의 총 크기 증가

    - DBMS 내부 I/O 내 대기시간 길어질 수 있음 -> I/O 가 적은게 좋음

 

6. 성능을 결정하는 요인

 - Optimizer 의 역할이 중요함

 - 옵티마이저 : 사용자가 원하는 작업을 효율적으로 수행할 수 있는 최적의 데이터 엑세스 경로를 선택해주는 DBMS 엔진

 - SQL 문 수행 순서 : SQL문 파싱 -> 최적화 -> Row 소스 생성

 

7. 실행 계획

Scan Type	Description
Table Full Scan	테이블 전체 레코드를 처음부터 끝까지 읽음
Index Range Scan	데이불의 일부 레코드에만 액세스

 - 인덱스를 이용해서 성능을 개선함 -> 변별력이 좋은 값을 사용하는 것이 중요함

 

8. 인덱스

 - B-Tree 구조, 정렬이 되어있음 -> 빠른 스캔 가능

 - 성능 향상에 유리함

 - SQL 문을 변경하지 않아도 성능 개선 가능

 - 테이블 데이터에 영향을 주지 않음

  1) 특징

구분	Description
균일성	어떤 값에 대해서도 같은 시간에 결과를 얻을 수 있음
이진탐색	정렬을 마친 데이터 구조 탐색에 좋음 -> 불균형 트리인 경우 성능 저하 발생
밸런스	루트로부터 리프까지의 거리가 일정 -> 성능 안정화 but 정기적으로 재구성을 통해 균형 회복 필요

  2) 역효과

종류	Description
갱신 오버헤드	테이블 데이터에 대한 갱신/제거 실행 시 자동으로 인덱스 갱신 대규모 처리 시 시간 증가
의도한 것과 다른 인덱스 사용됨	한 개의 테이블에 복수 인덱스가 있는 경우 튜닝 필요함
저장소 용량 차지	백업 시간 증가, 저장소 공간 비용 증가
느린 성능	변별력 없는 인덱스는 Full Scan 에 비해 성능이 안좋을 수 있음

  3) 인덱스 생성 원칙

원칙	Description
테이블 크기	크기가 큰 테이블이 효과적
기본키에는 불필요	기본키에는 기본적으로 인덱스가 자동으로 생성됨
선택도가 낮은 컬럼	선택도가 극히 낮은 컬럼에 만들면 극적인 성능 향상 가능
= 조건 컬럼에 사용	= 조건으로 조회되는 컬럼 우선 사용