인용하는 그림은 다양한 곳에서 가져왔음을 밝힙니다
1. DBMS 아키텍처
ch 1.DBMS 아키텍처 개요
1) 쿼리 평가 엔진
- SQL 구문을 분석하고, 어떤 순서로 기억장치의 데이터에 접근할지 결정 = 실행 계획(Explain plan)
- Access Method : 실행 계획에 기반을 둬서 데이터에 접근하는 방법
- 핵심 모듈이며 성능과도 깊은 관련이 있다
2) 버퍼 매니저
- 특별한 용도로 버퍼라는 메모리 영역을 확보해둔다
- 디스크 용량 매니저와 함께 작동한다
3) 디스크 용량 매니저
- 데이터를 어디에/어떻게 읽고 쓸지 관리
4) 트랜잭션 매니저와 락 매니저
- 동시 접근에 대한 안전성 제공
5) 리커버리 매니저
- 절대 잃어버리면 안되는 데이터를 장애로 잃었을시에 복구해주는 기능
ch 2. DBMS와 버퍼
1) 공짜 밥은 존재할까?
- 기억장치에 따른 트레이드오프, 무조건 좋은건 없다
2) DBMS가 기억장치의 관계
- DBMS는 데이터 저장을 목적으로 하는 미드뤠어 이며, 사용하는 대표적인 기억장치는 다음과 같다
(1) 하드디스크(HDD)
- DBMS가 데이터를 저장하는 대부분
(2) 메모리
- 성능 향상을 위해 올려둠, I/O를 줄이기 위해
(3) 버퍼를 활용한 속도 향상
- 성능 향상을 목적으로 데이터를 저장하는 메모리를 버퍼, 캐시
- 버퍼 매니저 : 버퍼에 데이터를 어떻게, 어느 정도 기간 동안 올릴지 결정
3) 메모리 위에 있는 두 개의 버퍼
- DBMS가 데이터를 유지하기 위해 사용하는 메모리는 크게. 1. 데이터 캐시, 2. 로그 버퍼
- MySQL DBMS의 버퍼 메모리와 제어 매개변수
| 명칭 | 버퍼 풀 |
|---|---|
| 매개변수 | innodb_buffuer_pool_size |
| 초기값 | 128MB |
| 설정값확인 | SHOW VARIABLES LIKE ‘innodb_buffer_pool_size’ |
| 명칭 | 로그 버퍼 |
|---|---|
| 매개변수 | innodb_log_buffer_size |
| 초기값 | 8MB |
| 설정값확인 | SHOW VARIABLES LIKE ‘innodb_log_buffer_size’ |
(1) 데이터 캐시
- 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 영역
- SELECT 하는 데이터가 캐시 영역에 있다면 빨라짐
(2) 로그 버퍼
- 갱신 처리(INSERT, DELETE, UPDATE, MERGE)와 관련
- 갱신 관련 SQL이 오면 로그버퍼에 변경 정보를 보내고 이후에 디스크 변경을 수행(비동기 처리)
4) 메모리 성질이 초래하는 트레이프오프
(1) 휘발성
- 장애 발생시 데이터가 날라가버려 부정합이 발생한다.
- 커밋 시점에 갱신정보를 로그 파일(HDD에 존재)에씀으로 정합성 유지
- 반대로 커밋시에는 디스크에 동기 저근이 일어나기 때문에 지연이 발생할 가능성이 높아진다
5) 시스템 특성에 따른 트레이드오프
(1) 데이터 캐시와 로그 버퍼의 크기
- 기본적으로 데이터 캐시에 비해 로그 버퍼의 초기값이 굉장히 작다. 그 이유는 주된 작업이 검색이라고 가정하기 때문이다.
(2) 검색과 갱신 중에서 중요한 것
6) 추가적인 메모리 영역 ‘워킹 메모리’
(1) 언제 사용될까?
- 2개의 버퍼 이외에도, 일반적인 메모리 영역을 하나더 가지고 있다
- 정렬 또는 해시 관련 처리에 사용되는 작업용 영역이다.
- 정렬은 ORDER BY, 집합 연산, 원도우 함수
- 해시는 테이블 결합시
- MySQL 에서는 정렬 버퍼, sort_buffuer_size = 257kb
- 이 영역이 성능적으로 중요한 이뉴는, 이 영역의 양이 부족하며 저장소를 사용하기 때문이다(Swap)
(2) 부족하면 무슨일이 일어 날까?
ch 3. DBMS와 실행 계획
1) 권한 이양의 죄악
- 절차가 기초가 되는 언어는 (C, 자바, 루비)는 절차를 책임지고 기술하지만, RDB는 대상(what)을 기술하기 때문에 그 외 작업은 DBMS에 맡겼다.
2) 데이터에 접근하는 방법은 어떻게 결정할까?
(1) 파서(parser) : 구문 분석
(2) 옵티마이저
- 인덱스 유무, 데이터 분산 or 편향 정도, DBMS 내부 매개변수를 고려해 여러 실행 계획을 작성하고, 비용을 연산한후 가장 비용이 낮은 실행계획을 선택한다
(3) 카탈로그 나머지
- 내부 정보를 모아 놓은 테이블로 옵티마이저에 중요한 정보를 제공한다
(4) 플랜 평가
- 최적의 실행 계획 선택
3) 옵티 마이저와 통계 정보
- 명령하는 대로 다처리해주는 만능이 아니다
- 통계 정보를 잘 관리해 줘야 한다
- 각 테이블의 레코드 수
- 각 테이블의 필드 수오 필드의 크기
- 필드의 카디널리티
- 필드 값의 히스토그램
- 인덱스 정보
4) 최적의 실행 계획이 작성되게 하려면
- 통계 정보를 잘 관리해줘야 한다. 갱신 필요
ch 4. 실행 계획이 SQL 구문의 성능을 결정
1) 실행 계획 확인 방법, EXPLAIN
- 참고로, 실행 계획의 실행 비용과 실행 시간은 추정값이기 때문에 맹신 해서는 안된다.
2) 테이블 풀 스캔의 실행 계획
| |
- 실행 계획의 공통 3가지(중요한 factor)
- 조직 대상 객체
- 객체에 대한 조작의 종류
- 조작 대상이 되는 레코드 수
(1) 조직 대상 객체
- 테이블, 인덱스, 시퀀스 처럼 SQL 구문으로 조작할 수 있는 객체
(2) 객체에 대한 조작의 종류
- 시퀀셜 스캔 ~ 풀 스캔
(3) 조작 대상이 되는 레코드 수
3) 인덱스 스캔의 실행 계획
- WHERE 조건 추가
4) 간단한 테이블 결합의 실행 계획(결합이 SQL의 주된 지연)
| |
- 결합에 3가지 알고리즘 사용
- Nested Loop : 한쪽 테이블을 읽으며, 다른 쪽 테이블을 읽어 조건에 맞는 레코드있는 지 확인
- Sort Merge : 결합 키로 레코드를 정렬(워킹 메모리 사용)
- Hash : 결합 키 값을 해시값으로 매핑. 워킹 메모리 필요.
- 결합시 테이블 접근 순서가 중요하다. 먼저 접근하는 테이블을 driving table 이라고 한다.
ch 5. 실행 계획의 중요성
- 힌트를 사용해 실행 계획 강제화 가능