1강 DBMS 아키텍쳐 개요
1) 쿼리 평가 엔진
- 쿼리 평가 엔진은 사용자로부터 입력받은 SQL 구문을 분석하고,
어떤 순서로 기억장치의 데이터에 접근할지를 결정합니다.
이 때, 결정되는 계획을 '실행 계획'이라고 합니다.
한마디로, 쿼리 평가 엔진은 계획을 세우고 실행하는 DBMS의 핵심 기능을 담당하는 모듈입니다.
2) 버퍼 매니저
- DBMS는 버퍼라는 특별한 용도로 사용하는 메모리 영역을 확보해둡니다.
이 메모리 영역을 관리하는 것이 바로 버퍼 매니저입니다.
3) 디스크 용량 매니저
- 디스크 용량 매니저는 어디에 어떻게 데이터를 저장할지를 관리하며,
데이터의 읽고 쓰기를 제어합니다.
4) 트랜잭션 매니저와 락 매니저
- 상용 시스템에서는 수천 명의 사람이 동시에 데이터베이스에 접근해서 사용하게 되는데,
이 때, 각각의 처리는 DBMS 내부에서 트랜잭션이라는 단위로 관리됩니다.
이러한 트랜잭션의 정합성을 유지하면서 실행시키고,
필요한 경우 데이터에 락을 걸어 다른 사람의 요청을 대기시키는 것이
트랜잭션 매니저와 락 매니저의 역할입니다.
5) 리커버리 매니저
- DBMS가 저장하고 있는 데이터 중에는 절대 잃어버리면 안 되는 데이터가 있습니다.
하지만 시스템은 언제나 장애가 발생할 수 있습니다.
따라서 이러한 상호아을 대비하려면 데이터를 정기적으로 백업하고,
문제가 일어났을 때 복구해줘야 되는데,
이러한 기능을 수행하는 것이 리커버리 매니저입니다.
2강 DBMS와 버퍼
- 버퍼는 성능에 굉장히 중요한 영향을 미칩니다.
메모리는 한정된 희소한 자원이므로,
데이터를 버퍼에 어떠한 식으로 확보할 것인가 하는 부분에서 트레이드오프가 발생합니다.
- 디스크 접근을 줄일 수 있다면, 굉장히 큰 폭의 성능 향상이 가능합니다.
이는 일반적인 SQL 구문의 실행 시간 대부분을 저장소 I/O에 사용하기 때문입니다.
- 성능 향상을 목적으로 데이터를 저장하는 메모리를 버퍼(buffer) 또는 캐시(cache)라고 부릅니다.
사용자와 저장소 사이에서 SQL 구문의 디스크 접근을 줄여주는 역할을 하므로 붙은 이름입니다.
- DBMS가 데이터를 유지하기 위해 사용하는 메모리는 크게 다음과 같이 두 종류입니다.
1) 데이터 캐시
2) 로그 버퍼
1) 데이터 캐시
- 데이터 캐시는 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해
사용하는 메모리 영역입니다.
2) 로그 버퍼
- 로그 버퍼는 갱신 처리(INSERT, DELETE, UPDATE, MERGE)와 관련 있습니다.
- DBMS는 결국 '저장소의 느림을 어떻게 보완할 것인가'라는 것을 계속해서 고민해온 미들웨어입니다.
- 메모리의 성질이 초래하는 트레이드오프가 몇 가지 있습니다.
1) 휘발성
- 메모리에는 데이터의 영속성이 없습니다.
하드웨어의 전원을 꺼버리면 메모리 위에 올라가 있는 모든 데이터가 사라져 버립니다.
이를 '휘발성'이라고 합니다.
2) 휘발성의 문제점
- 데이터 캐시라면 장애로 인해 메모리 위의 데이터가 사라져버려도,
원본 데이터는 디스크 위에 남아 있으므로 아무 문제 없습니다.
하지만 로그 버퍼 위에 존재하는 데이터가 디스크 위의 로그 파일에 반영되기 전에
장애가 발생해서 사라져버린다면, 해당 데이터가 완전히 사라져서 복구조차 불가능합니다.
-> 이를 회피하고자 DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일에 씀으로써,
장애가 발생해도 정합성을 유지할 수 있게 합니다.
- 데이터 캐시와 로그 버퍼를 비교해보면
3개의 DBMS에 공통으로 데이터 캐시에 비해
로그 버퍼의 초깃값이 굉장히 작다는 것을 알 수 있습니다.
-> 이렇게 2개의 버퍼에 대해 극단적으로 비대칭적인 크기를 할당한 이유는
데이터베이스가 기본적으로 검색을 메인으로 처리한다고 가정하기 때문입니다.
- DBMS는 앞에서 설명했던 2개의 버퍼 이외에도,
일반적으로 메모리 영역을 하나 더 가지고 있습니다.
이는 정렬 또는 해시 관련 처리에 사용되는 작업용 영역으로
워킹 메모리(Working Memory)라고 합니다.
- 이 작업용 메모리 영역은 SQL에서 정렬 또는 해시가 필요한 때 사용되고,
종료되면 해제되는 임시 영역으로,
일반적으로 데이터 캐시와 로그 버퍼와는 다른 영역으로 관리되는 경우가 많습니다.
-> 이 영역이 성능적으로 중요한 이유는
만약 이 영역이 다루려는 데이터양보다 작아 부족해지는 경우가 생기면
대부분의 DBMS가 저장소를 사용하기 때문입니다.
3강 DBMS와 실행 계획
- RDB에서 데이터 접근 절차를 결정하는 모듈은 쿼리 평가 엔진이라고 부릅니다.
쿼리 평가 엔진은 사용자로부터 입력받은 SQL 구문(쿼리)을 처음 읽어들이는 모듈이기도 합니다.
쿼리 평가 모듈은 추가로 파서 또는 옵티마이저와 같은 여러 개의 서브 모듈로 구성됩니다.
1) 파서
- 파서의 역할은 이름 그대로 파스(구문 분석)하는 것입니다.
사용자로부터 입력 받은 SQL 구문이 항상 구문적으로 올바르다는 보증이 없으므로
검사를 해주는 것입니다.
2) 옵티마이저
- 서류 심사를 통과한 쿼리는 옵티마이저로 전송됩니다. 옵티마이저의 한국어 번역은 '최적화'입니다.
이 때 최적화의 대상은 데이터 접근법(실행 계획)입니다.
옵티마이저가 바로 DBMS 두뇌의 핵심입니다.
- 옵티마이저는 인덱스 유무, 데이터 분산 또는 편향 정도, DBMS 내부 매개변수 등의 조건을 고려해서,
선택 가능한 많은 실행 계획을 작성하고, 이들의 비용을 연산하고,
가장 낮은 비용을 가진 실행 계획을 선택합니다.
3) 카탈로그 매니저
- 옵티마이저가 실행 계획을 세울 때, 옵티마이저에 중요한 정보를 제공하는 것이 카탈로그 매니저입니다.
카탈로그란 DBMS의 내부 정보를 모아놓은 테이블로, 테이블 또는 인덱스의 통계 정보가 저장되어 있습니다.
4) 플랜 평가
- 옵티마이저가 SQL 구문에서 여러 개의 실행 계획을 세운 뒤
그것을 받아 최적의 실행 결과를 선택하는 것이 플랜 평가입니다.
- 플랜 선택을 옵티마이저에게 맡기는 경우, 실제로 최적의 플랜이 선택되지 않는 경우가 꽤 많습니다.
옵티마이저가 실패하는 패턴이 몇 가지 있는데,
통계 정보가 부족한 경우가 대표적인 원인으로 꼽힙니다.
- 구현에 따라 차이는 있지만,
카탈로그에 포함되어 있는 통계 정보는 다음과 같은 것들입니다.
(1) 각 테이블의 레코드 수
(2) 각 테이블의 필드 수와 필드의 크기
(3) 필드의 카디널리티(값의 개수)
(4) 필드값의 히스토그램
(5) 필드 내부에 있는 NULL 수
(6) 인덱스 정보
-> 이러한 정보를 활용함으로써 옵티마이저는 실행 계획을 만듭니다.
문제가 생기는 경우는 이러한 카탈로그 정보가 테이블 또는 인덱스의 실제와
일치하지 않을 때입니다.
- 올바른 통계 정보가 모이는 것은 SQL 성능에 있어서 굉장히 중요한 문제입니다.
따라서 테이블의 데이터가 많이 바뀌면 카탈로그의 통계 정보도 함께 갱신해야 한다는 것은
데이터베이스 엔지니어 사이의 상식입니다.
4강 실행 계획이 SQL 구문의 성능을 결정
- 실행 계획이 만들어지면 DBMS는 그것을 바탕으로 데이터 접근을 수행합니다.
- 지금부터 다음과 같은 3개의 기본적인 SQL 구문의 실행 계획을 살펴보겠습니다.
(1) 테이블 풀 스캔
(2) 인덱스 스캔
(3) 간단한 테이블 결합
(1) 테이블 풀 스캔
- 다음과 같은 3가지는 거의 모든 DBMS의 실행 계획에 포함되어 있습니다.
(1-1) 조작 대상 객체
(1-2) 객체에 대한 조작의 종류
(1-3) 조작 대상이 되는 레코드 수
(2) 인덱스 스캔
- 인덱스 스캔은 일반적으로는 스캔하는 모집합 레코드 수에서 선택되는 레코드 수가 적다면
테이블 풀 스캔보다 빠르게 접근을 수행합니다.
이는 풀 스캔이 모집합의 데이터양에 비례해서 처리 비용이 늘어나는 것에 반해,
인덱스를 사용할 때 활용되는 B-tree가 모집합의 데이터양에 따라
대수 함수적으로 처리 비용이 늘어나기 때문입니다.
(3) 간단한 테이블 결합
- 결합을 사용하면 실행 계획이 상당히 복잡해지므로, 옵티마이저도 최적의 실행 계획을 세우기 어렵습니다.
따라서 결합 시점의 실행 계획 특성을 공부하는 것은 굉장히 중요한 의미가 있습니다.
참고
- SQL 레벨업
'DB' 카테고리의 다른 글
| SQL 레벨업 6장 결합 (1) | 2022.04.25 |
|---|---|
| SQL 레벨업 5장 반복문 (2) (1) | 2022.04.25 |
| SQL 레벨업 5장 반복문 (1) (1) | 2022.04.18 |
| SQL 레벨업 4장 집약과 자르기 (1) | 2022.04.18 |
| SQL 레벨업 3장 SQL의 조건 분기 (1) | 2022.04.11 |