데이터베이스 첫걸음 - 성능!
성능학습이 중요한 이유
학습용으로 작은 데이터들을 다룰 때는 아무런 문제가 되지 않지만,
데이터베이스를 다루는 한 미래에 언젠가는 반드시 성능 문제로 고민하게 된다
성능이란?
처리 속도를 말한다.
성능을 측정하는 지표는 처리시간이나 응답시간이 있고, 처리율이 있다.
처리율은 자동차 속도처럼 예를 들면 트랜잭션을 초당 50건 이런 식으로 말할 수 있고 더 고급지게 말하려면 50 TPS (Transaction per sec) 가 처리율이라고 말할 수 있다.
성능의 한계
물리적 자원은 한정되어 있기 때문에 사용자수가 많아지면 어느 순간 성능에 한계가 올수있다. 이때 한계에 다다른 시점에서 성능이 나빠지기 시작한다.
이를 대비해 자원을 확보해 두는 것을 Sizing 또는 Capacity Planning 이라고 한다.
데이터베이스와 병목
물줄기가 잘흐르다가 병의 목부분처럼 좁아지면 어떻게 되는가?
병목은 말그대로 병의 목부분을 말한다.
데이터베이스는 왜 병목이 되는가?
취급하는 데이터양이 가장 많다. 시스템에서 처리하는 데이터 전체를 일괄로 보관하는 장소이기 때문이다.
자원 증가를 통한 해결이 어렵다.
데이터베이스의 병목 지점은 CPU나 메모리가 아닌 저장소이다. 스케일아웃이 어려운 지점이기 때문이다.
튜닝
이런 제한 때문에 데이터베이스는 전통적으로 튜닝 기술이 발달해있다.
튜닝은 어플리케이션을 효율화해서 같은 양의 자원이라도 성능을 향상하게 하는 기술이다.
데이터베이스에 한정해서 말하면 SQL을 어떻게 빠르게할 수 있을까? 정도가 된다.
성능을 결정하는 요인
SQL문의 성능을 고려한다면 데이터베이스가 내부에서 SQL문을 어떻게 처리하는지 알아야한다.
가장 먼저 구문 오류를 체크하는 파서가 있는데, 이것이 SQL문 처리의 1단계이다.
그 다음으로 내가 입력한 SQL 문으로부터 어떤 계획을 세우려고 한다. SQL 문에 필요한 데이터에 어떤 경로로 접근할까? 하는 계획이다.
SQL문에 필요한 데이터를 얻는 방법은 단 한가지가 아니라 여러개가 있을 수 있으므로 데이터베이스는 어떤 계획으로 데이터에 도달할지 결정해야한다.
이것이 옵티마이저(Optimizer)가 하는 일이다.
Java 와 같이 프로그래밍 언어로 작성할떄는 이런 프로세스는 존재하지 않는다. 자신이 어떻게 데이터에 액세스할지 코딩을 해야하기 때문이다.
그래서 옵티마이저는 데이터베이스의 두뇌라고 해도 과언이 아니다.
옵티마이저에게 실행계획을 맡기는 이유
사람보다 더 낫다.
옵티마이저가 참조하는 통계정보
옵티마이저는 그냥 실행계획을 세우는게아니라 통계정보(Statistics)를 참조해서 계획을 세운다.
통계정보는 show table status;나 show index from 테이블명;으로 확인할수있다.
통계정보는 기본적으로는 대부분 자동으로 수집되어 구현된다.
analyze table 테이블명;으로 수동으로 통계정보를 수집할 수도있다.
실행계획은 어떻게 세워지는가?
SQL문의 실행계획은 EXPLAIN 명령어로 확인 할 수 있다.
여러가지 정보중에 type 같은 경우에는 ALL 과 RANGE 가 있는데, 풀스캔과 레인지스캔을 뜻한다. 인덱스가 있을 경우에는 RANGE이다.
인덱스
인덱스는 create index 인덱스명 on 테이블명(컬럼명);으로 만들 수 있다.
중요한 점은 사용자는 인덱스를 만들기만 해도 특별히 이 인덱스를 사용하라고 지시를 DBMS에 하지 않아도 DBMS의 옵티마이저는 자동으로 빠른 실행계획을 세운다.
인덱스는 데이터베이스의 성능 향상 수단으로 쓰이는 가장 일반적인 방법이고 응답시간이 늦은 SQL이 발견되면 우선 인덱스로 해결할수없는지 검사하는 것이 튜닝의 첫걸음이다.
인덱스를 사용하면
- SQL문을 변경하지 않아도 성능을 개선 가능
- 테이블 데이터에 영향을 주지 않음
- 일정한, 극적인 효과를 기대
show index from 테이블명;으로 인덱스 통계정보를 보면 Index_type에 BTREE라는 키워드를 볼 수 있다.
보통 B-tree라고 쓰이고 데이터베이스에서 튜닝의 기본이 되는 인덱스이다.
B-tree는 선형탐색(처음부터 끝까지 하나씩 탐색)에 반해서 성능이 균형적이다.
그래서 B-tree가 Balanced-tree 라는 설까지 있다.
B-tree는 데이터양에 비례해 효과가 오른다.
그래프를 그리면 x축 데이터양, y축 처리시간 에 대해 로그함수 곡선을 그린다.
인덱스의 단점
- 인덱스 갱신의 오버헤드로 갱신 처리의 성능이 떨어짐
- 옵티마이저가 가끔 내가 의도한것과 다른 인덱스를 사용 (항상 똑똑한것은 아니다)
인덱스를 만드는 기준
- 크기가 큰 테이블에만 만든다. 작은테이블은 풀스캔해도 성능이 차이가 없다.
- primary key나 unique 제약이 부여된 열에는 불필요하다. 값의 중복 체크를 하려면 데이터를 정렬해야하는데 인덱스를 작성해 정렬하는 것이 편리하기 때문.(B-tree 인덱스는 반드시 데이터를 정렬한 상태를 유지해야함)
- Cardinality가 높은 열에 만든다. Cardinality가 낮은 열에 인덱스를 붙이는건 안붙이는 것만 못하다. 오버헤드가 생긴다.
잡담
얏호 데이터베이스 첫걸음 드뎌 끝났따!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
