인용하는 그림은 다양한 곳에서 가져왔음을 밝힙니다

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의 버퍼 메모리와 제어 매개변수

(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) 테이블 풀 스캔의 실행 계획

1

* SELECT * FROM Shops;

• 실행 계획의 공통 3가지(중요한 factor)
  • 조직 대상 객체
  • 객체에 대한 조작의 종류
  • 조작 대상이 되는 레코드 수

(1) 조직 대상 객체

• 테이블, 인덱스, 시퀀스 처럼 SQL 구문으로 조작할 수 있는 객체

(2) 객체에 대한 조작의 종류

• 시퀀셜 스캔 ~ 풀 스캔

(3) 조작 대상이 되는 레코드 수

3) 인덱스 스캔의 실행 계획

• WHERE 조건 추가

4) 간단한 테이블 결합의 실행 계획(결합이 SQL의 주된 지연)

1

* SELECT shop_name FROM shops S INNER JOIN Reservations R On S.shop_id = R.shop_id;

• 결합에 3가지 알고리즘 사용
  • 1. Nested Loop : 한쪽 테이블을 읽으며, 다른 쪽 테이블을 읽어 조건에 맞는 레코드있는 지 확인
  • 2. Sort Merge : 결합 키로 레코드를 정렬(워킹 메모리 사용)
  • 3. Hash : 결합 키 값을 해시값으로 매핑. 워킹 메모리 필요.
• 결합시 테이블 접근 순서가 중요하다. 먼저 접근하는 테이블을 driving table 이라고 한다.

ch 5. 실행 계획의 중요성

• 힌트를 사용해 실행 계획 강제화 가능