19.05.05 데이터베이스 성능

-성능이란?-

 

성능은 기본적으로 '빠르기' 를 중심으로 한 개념입니다.

성능은 2가지 지표 (매트릭스)에 의해 측정됩니다.

한 가지는 '처리 시간' 또는 '응답 시간' 이라고 불리는 지표이고, 다른 한가지는 '처리율' 입니다.

 

 

 

-처리시간-

 

이들은 어떤 특정 처리의 시작부터 종료까지 걸린 시간을 나타냅니다.

 

 

 

-처리율-

 

시스템에서는 '특정 처리(트랜잭션)를 단위 시간에 몇 건 처리가 가능한가' 에 대한

측정 단위를 나타냅니다.

시스템의 자원용량을 결정하는 요인

 

 

 

-버틀넥 포인트(병목)-

 

동시 실행 처리수가 증가 할수록 준비해야 할 자원도 증가하며 한 가지 자원이라도 한계에 이른 시점에서 성능이 나빠지기 시작합니다.

즉, 응답 시간이 상승하기 시작하고, 반대로 처리율이 떨어지기 시작합니다. 이때 최초로 한계에 이른 자원을 '버틀넥포인트' 또는 '병목' 이라고 합니다.

 

 

 

-데이터베이스가 병목되는 이유-

 

1. 취급하는 데이터양이 가장 많다.     2. 자원 증가를 통한 해결이 어렵다

 

 

 

-테이블에 대한 액세스 방법-

 

풀 스캔 (ALL) : 테이블에 포함된 레코드를 처음부터 끝까지 전부 잃어 들이는 방법으로, '테이블 풀 스캔'이라고 합니다.     레인지 스캔(rangd) : 테이블의 일부 레코드에만 액세스하는 방법

 

 

 

-데이터베이스가 결과를 통지하는 과정-

 

1. 구문 오류가 없는지를 보는 파스     2. 실행계획 (어떤 경로로 접근할까? 하는 계획) 과 옵티마이저 (실행계획을 결정하는 내부 프로그램),      통계정보 (옵티마이저가 실행계획을 세울 때 참조하는 정보)

 

 

 

-인덱스의 구조-

 

인덱스는 데이터베이스의 성능 향상 수단으로 가장 일반적인 방법입니다.

응답 시간이 늦은 SQL이 발견되면 우선 인덱스로 해결할 수 없는지를 검사하는 것이 튜닝의 제1선택입니다.

인덱스의 인기가 높은 이유는 다음 3가지 입니다.

 

1. SQL 문을 변경하지 않아도 성능을 개선할 수 있다.     2. 테이블의 데이터에 영향을 주지 않는다.     3. 일정한 (때로는 극적인) 효과를 기대할 수 있다.

 

쉽게 말하는 인덱스는 비용 대비 성능이 높은 방법입니다.

인덱스가 나무 형태를 하고 있는 것을 일반적으로 'B-tree' 라고 합니다.

B-tree는 관계형 데이터베이스에서 튜닝의 기본이 되는 인덱스 입니다.

 

 

 

-B-tree의 구조-

 

그림에서 원으로 표시된 한개의 데이터를 '노드' 라고 합니다.

가장 위의 노드를 '루트 노드' 라고 하는데, '뿌리' 라는 의미입니다.

가장 아래 노드를 '리프 노드' 라고 하고, '잎' 이라는 의미입니다.

중간 노드는 가지라는 뜻에서 '브랜치 노드' 로 부릅니다.

 

 

 

 

 

-B-tree의 장점-

 

장점 한 가지는 어떤 값에 대해서도 같은 시간에 결과를 얻을 수 있다. (균일성)

데이터양에 증가할수록 우수한 개선 효과를 발휘한다.

 

 

 

-인덱스 작성이 역효과가 날때-

 

* 인덱스 갱신의 오버헤드로 갱신 처리의 성능이 떨어진다.     인덱스는 테이블에 새로운 데이터가 추가되거나 기존의 데이터에  대해 갱신, 제거가 실행되면   자동으로 인덱스 자신도 갱신하는 기능을 갖추고 있습니다. 테이블을 책이라고 했을 때   본문이 변경되면 거기에 대응해서 색인도 자동으로 갱신되는 것입니다.   이것 자체는 매우 우수한 기능이지만, 그 대가로 인덱스가 존재하지 않는 때와 비교하면   갱신할 때마다 인덱스 갱신도 부수적으로 발생합니다.   이것도 오버헤드의 일종입니다.       * 의도한 것과 다른 인덱스가 사용된다.     이것은 한 개의 테이블에 복수의 인덱스를 작성한 경우에 발생하는 문제입니다.   업무의 중심이 되는 테이블은 다양한 SQL 문에서 이용되며, 거기에 대응해 작성된   인덱스 수도 많아지게 됩니다.   앞에서 예로 든 모든 열에 인덱스를 만든다는 것은 너무 극단적이라고 하더라도,   10~20개 정도의 인덱스가 1개의 테이블에 만들어져 있는 것도 드물지는 않습니다.   더 빠른 인덱스가 있을 텐데 의도한 것과는 다른 인덱스가 사용되어 오히려   느려진 예입니다.       * 트레이드오프     인덱스를 만들면 그만큼 저장소 용량을 소비한다.

 

 

 

-인덱스를 만들 때 기준-

 

* 크기가 큰 테이블만 만든다.     크기가 작은 테이블에는 애초에 인덱스도 풀 스캔도 큰 차이가 없기 때문.       * 기본키 제약이나 유일성 제약이 부여된 열에는 불필요하다.     기본키 제약이 부여된 열에는 자동으로 인덱스가 작성되어 있기 때문     * Cardinality 가 높은 열에 만든다.     'Cardinality' 란 값의 분산도를 나타내는 단어로, 특정 열에 대해 많은 종류의 값을 가지고 있다면 높고, 값의 종류가 적으면   낮다는 의미입니다.   'Cardinality' 가 낮은 열에 인덱스 효과를 기대할 수 없는 것은 인덱스 트리를 따라가는 조작이 증가할수록   오버헤드가 증가해 인덱스를 작성한 혜택을 받지 못하기 때문입니다.