1장 DBMS 아키텍처

1. DBMS 아키텍처 개요

1. 쿼리 평가 엔진

- 쿼리 평가 엔진 : 사용자로부터 입력받은 SQL 구문을 분석하고, ,어떤 순서로 기억장치의 데이터에 접근할지를 결정한다.

- 이때 결정되는 계획을 '실행 계획'라고 부른다.

- 접근 메서드(access method) : 실행 게획에 기반을 둬서 데이터에 접근하는 방법

- 한마디로 쿼리 평가 엔진은 계획을 세우고 실행하는 DBMS의 핵심 기능을 담당하는 모듈이다.

 

2. 버퍼 매니저

- DBMS는 버퍼라는 특별한 용도로 사용하는 메모리 영역을 확보해둔다.

- 이 메모리 영역을 관리하는 것이 바로 버퍼 매니저이다.

- 버퍼 매니지는 디스크를 관리하는 디스크 용량 매니저와 함께 연동되어 작동한다.

 

3. 디스크 용량 매니저

- 데이터베이스는 데이터를 영구적으로 저장해야 한다.

- 디스크 용량 매니저는 어디에 어떻게 데이터를 저장할지를 관리하며, 데이터의 읽고 쓰기를 제어한다.

 

4. 트랜잭션 매니저와 락 매니저

- DB 각각의 처리는 DBMS 내부에서 트랜잭션이라는 단위로 관리된다.

- 이러한 트랜잭션의 정합성을 유지하면서 실행시키고, 필요한 경우 데이터에 락을 걸어 다른 사람의 요청을 대기시키는 것이 트랜잭션 매니저와 락 매니저의 역할이다.

 

5. 리커버리 매니저

- 데이터를 정기적으로 백업하고, 문제가 일어났을 때 복구해줘야하는 역할을 하는 것이 리커버리 매니저이다.

 

2. DBMS와 버퍼

- 데이터를 버퍼에 어떠한 식으로 확보할 것인가 하는 부분에서 트레이드오프 발생

 

1. 공짜 밥은 존재할까?

- 기억장치는 기억 비용에 따라 1차부터 3차까지의 계층으로 분류한다.

- 기억비용 : 데이터를 저장하는 데 소모되는 비용

- 많은 데이터를 영속적으로 저장하려 하면 속도를 잃고, 속도를 얻고자 하면 많은 데이터를 영속적으로 저장하기 힘들다는 트레이드 오프 발생

 

2. DBMS와 기억장치의 관계

- DMBS가 사용하는 대표적인 기억 장치

    ㆍ하드디스크(HDD)

    ㆍ메모리

 

하드디스크(HDD)

- DBMS가 데이터를 저장하는 매체(저장소)는 현재 대부분 HDD이다.

- 하드디스크는 기억장치 계층에서 한가운데에 있는 2차 기억장치로 분류된다.

- 2차 기억장치는 그렇게 좋은 장점도 없지만, 그렇게 나쁜 단점도 없는 매체이다.

 

메모리

- 메모리는 디스크에 비해 기억 비용이 굉장히 비싸다.

- 일반적인 데이터베이스 서버의 경우 탑재되는 메모리 양은 한두 자리 정도이다.

 

버퍼를 활용한 속도 향상

- DBMS가 일부라도 데이터를 메모리에 올리는 것이 성능 향상 때문이다.

- 메모리는 가장 빠른 1차 기억장치이다.

- 따라서 자주 접근하는 데이터를 메모리 위에 올려둔다면, 같은 SQL 구문을 실행한다고 해도 디스크에서 데이터를 가져올 필요 없이 곧바로 메모리에서 읽어 빠르게 데이터를 검색할 수 있다.

- 디스크 접근을 줄일 수 있다면 굉장히 큰 퐥의 성능 향상이 가능하다.

 

- 성능 향상을 목적으로 데이터를 저장하는 메모리를 버퍼(buffer) 또는 캐시(cache)라고 부른다.

- 버퍼는 '완충제'라는 의미로, 사용자와 저장소 사이에서 SQL 구문의 디스크 접근을 줄여주는 역할을 하므로 붙은 이름

- 캐시 역시 사용자와 저장소 사이에서 데이터 전송 지연을 완화시켜주는 것이다.

 

- 고속 접근이 가능한 버퍼에 '데이터를 어떻게, 어느 정도의 기간 동안 올릴지'를 관리하는 것이 DBMS의 버퍼 매니저이다.

 

3. 메모리 위에 있는 두 개의 버퍼

- DBMS가 데이터를 유지하기 위해 사용하는 메모리는 크게 다음 2종류이다

    ㆍ데이터 캐시

    ㆍ로그 버퍼

- 대부분의 DBMS는 이러한 두 개의 역할을 하는 메모리 영역을 가지고 있다.

- 이러한 버퍼는 사용자가 용도에 따라 크기를 변경하는 것이 가능하다.

 

데이터 캐시

- 데이터 캐시는 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 메모리 영역

 

로그 버퍼

- 로그 버퍼는 갱신 처리와 관련이 있다.

- DBMS는 갱신과 관련된 SQL 구문을 사용자로부터 받으면, 곧바로 저장소에 있는 데이터를 변경하지 않는다.

- 일단 로그 버퍼 위에 변경 정보를 보내고 이후 디스크에 변경을 수행한다.

 

4. 메모리의 성질이 초래하는 트레이드 오프

휘발성

- 메모리에는 데이터의 영속성이 없다.

 

휘발성의 문제점

- 휘발성의 가장 큰 문제점은 장애가 발생했을 때 메모리에 있던 데이터가 모두 사라져버려 데이터 부정합이 발생시키는 것이다.

- 데이터 캐시라면 장애로 인해 메모리 위의 데이터가 사라져도, 원본 데이터는 디스크 위에 남아 있으므로 문제가 없다.

- 하지만 로그 버퍼 위에 존재하는 데이터가 디스크 위의 로그 파일로 반영되기 전에 장애가 발생해서 사라진다면 복구 불가능!

- 이를 회파하고자 DBMS는 커밋 시점에 반드시 갱신 정보를 로그파일에 씀으로써, 장애가 발생해도 정합서을 유지할 수 있게 한다.

- 커밋 : 갱신 처리를 확정하는 것

- DBMS는 커밋된 데이터를 영속화한다.

- 반대로 말하면 커밋 때는 반드시 디스크 동기 접근이 일어나므로 지연이 발생할 가능성이 있다.

- 디스크에 동기 처리를 한다면 데이터 정합성은 높아지지만 성능이 낮아지고,

   반대로 성능을 높일려면 데이터 정합성이 낮아진다.

 

5. 시스템 특성에 따른 트레이드 오프

데이터 캐시와 로그 버퍼의 크기

- 데이터 캐시에 비해 로그 버퍼의 초깃값이 굉장히 작다.

 

검색과 갱신 중에서 중요한 것

- 로그 버퍼가 크게 잡혀있다면, 갱신 처리와 관련해 큰 부하가 걸릴 것을 고려한 설계

- 반대로 데이터 캐시가 크게 잡혀있다면 검색 처리와 관련된 처리가 중심

 

6. 추가적인 메모리 영역 '워킹 메모리'

언제 사용될까?

- 워킹 메모리 : 정렬 또는 해시 관련 처리에 사용되는 작업용 영역

- 정렬은 ORDER BY 구, 집합 연산, 윈도우 함수 등의 기능을 사용할 때 실행된다.

- 반면 해시는 주로 테이블 등의 결합에서 해시 결합이 사용되는 실행된다.

- 종료되면 해제되는 임시영역으로, 일반적으로 데이터 캐시와 로그 버퍼와는 다른 영역으로 관리되는 경우가 많다.

- 이 영역이 성능적으로 중요한 이유는, 만약 이 영역을 다루는 데이터양보다 작아 부족해지는 경우가 생기면 DBMS가 저장소를 사용하기 때문이다.

 

부족하면 무슨 일이 일어날까?

- 메모리가 부족해지는 순간 갑자기 느려지는 순간적인 변화가 일어나는 것이 문제이다.

- DBMS는 '메모리가 부족하더라도 무언가를 처리하려고 계속 노력하는 미들웨어'

 

3. DBMS와 실행 계획

1. 권항 이양의 죄악

- SQL은 절차적인 것을 전혀 기술하지 않는다.

 

2. 데이터에 접근하는 방법은 어떻게 결정할까?

- 쿼리 평가 엔진은 사용자로부터 입력받은 SQL 구문(쿼리)을 처음 읽어들이는 모듈이기도 하다.

- 쿼리 평가 모듈은 추가로 파서 도는 옵티마이저와 같은 여러 개의 서브 모듈로 구성된다.

 

파서(parser)

- 파서의 역할은 이름 그대로 파스(구문 분석)하는 것이다.

- 사용자로부터 입력받은 SQL 구문이 항상 구문적으로 올바르다는 보증이 없으므로 검사를 해주는 것이다.

- 또는  파서는 SQL 구문을 정형적인 형식으로 변환해준다.

- 그렇게 해야 DBMS 내부에서 일어나는 후속 처리가 효율화된다

 

옵티마이저(optimizer)

- 서류 심사를 통과한 쿼리는 옵티마이저로 전송된다.

- 옵티마이저의 한국어 번역은 '최적화'이다

- 이때 최적화의 대상은 데이터 접근법(실행 계획)이다.

- 옵티마이저가 바로 DBMS 두뇌의 핵심

- 옵티마이저는 인덱스 유무, 데이터 분산 또는 편향 정도, DBMS 내부 매개변수 등의 조건을 고려해서, 선택 가능한 많은 실행 계획을 작성하고, 이들의 비용을 연산하고, 가장 낮은 비용을 가진 실행 계획을 선택한다.

 

카탈로그 매니저(catalog manager)

- 옵티마이저가 실행 계획을 세울 때 옵티만이저에 중요한 정보를 제공하는 것이 카탈로그 매니저이다.

- 카탈로그란 DBMS의 내부 정보를 모아놓은 테이블들로, 테이블 또는 인덱스의 통계 정보가 저장되어 있다.

- 이러한 카탈로그 정보를 간단하게 '통계 정보'라고 부르기도 한다.

 

 플랜 평가

- 옵티마이저가 SQL 구문에서 여러 개의 실행 계획을 세운 뒤 그것을 받아 최적의 실행 결과를 선택하는 것이 플랜 평가이다.

- 실행 계획이라는 것은 곧바로 DBMS가 실행할 수 있는 형태의 코드가 아니다. - 수정방안 등을 고려

 

3. 옵티마이저와 통계 정보

- 옵티마이저가 명령하는 대로 다 잘 처리해주는 만능은 아니다.

- 특히 카탈로그 매니저가 관리하는 통계 정보에 대해서는 데이터베이스 엔지니어가 항상 신경 써줘야 한다.

- 카탈로그에 포함되어 있는 통계 정보

    ㆍ각 테이블의 레코드 수

    ㆍ각 테이블의 필드 수와 필드의 크기

    ㆍ필드의 카디널리티(cardinality)(값의 개수)

    ㆍ필드값의 히스토그램(어떤 값이 얼마나 분포되어 있는가)

    ㆍ필드 내부에 있는 NULL 수

    ㆍ인덱스 정보

- 이러한 정보를 활용함으로써 옵티마이저는 실행 계획을 만든다.

- 문제가 생기는 경우는 이러한 카탈로그 정보가 테이블 또는 인덱스의 실제와 일치하지 않을 때이다.

    ㆍ테이블에 갱신이 수행될때 카탈로그 정보가 갱신되지 않는다면, 옵티마이저는 오래된 정보로 실행 계획을 세움

 

4. 최적의 실행 계획이 작성되게 하려면

- 통계 정보 갱신은 대상 테이블 또는 인덱스의 크기와 수에 따라서 몇십 분에서 몇 시간이 소요되기도 하는, 실행 비용이 굉장히 높은 작업이다.

- 하지만 DBMS가 최적의 플랜을 선택하려면 필요한 조건이므로 갱신 시점을 확실하게 검토해야 한다.

 

4. 실행 계획이 SQL 구문의 성능을 결정

- 통계 정보가 최신이라도 SQL 구문이 너무 복잡하면 옵티마이저가 최적의 접근 경로를 선택하지 못할 수도 있다.

1. 실행 계획 확인 방법

- SQL 구문의 지연이 발생했을 때 제일 먼저 실행 계획을 살펴봐야 한다.

- 실행 계획을 확인하는 명령어

PostgreSQL	EXPLAIN SQL 구문
MySQL	EXPLAIN EXTENDED SQL 구문

 

2. 테이블 풀 스캔의 실행 계획

- 모든 DBMS의 실행 계획에 포함되는 것

    ㆍ1. 조작 대상 객체

    ㆍ2. 객체에 대한 조작의 종류

    ㆍ3. 조작 대상이 되는 레코드

 

조작 대상 객체

- postgreSQL은 on 글자 뒤 / Oracle은 Name 필드

- 여러 개의 테이블을 사용하는 SQL 구문에서는 어떤 객체를 조작하는지 혼동하지 않게 주의가 필요하다.

- 또한 이 부분은 테이블 이외에도 인덱스, 파티션, 시퀀스처럼 SQL 구문으로 조작할 수 있는 객체라면 무엇이라도 올 수 있다.

 

객체에 대한 조작의 종류

- 객체에 대한 조작의 종류는 실행 계획에서 가장 중요한 부분이다.

- postgreSQL은 문장의 앞부분에 나오며, Oracle에서는 'Operation' 필드로 나타난다.

    ㆍPostgreSQL의 'Seq Scan'은 '순차적인 접근'의 줄임말로 '파일을 순차적으로 접근해서 해당 테이블의 데이터 전체를 읽어낸다'

    ㆍoracle의 'TABLE ACCESS FULL'은 '테이블의 데이터를 전부 읽어들인다'

 

* 실행 계획에 출력되는 비용 또는 실행 시간, 처리 레코드 수는 추정값이므로 절대 지표로 사용하면 안된다.

 

조작 대상이 되는 레코드 수

- 두 가지 DBMS 모두 Rows 라는 항목으로 출력된다.

- 결합 또는 집약이 포함되면 1개의 SQL 구문을 실행해도 여러 개의 조작이 수행된다.

- 각 조작에서 얼마만큼 레코드가 처리되는지가 SQL 구문 전체의 실행 비용을 파악하는 데 중요한 지표가 된다.

- 옵티마이저가 어디까지나 통계라는 메타 정보를 믿기 때문에, 실제 테이블을 제대로 보지 않는다는 증거이다.

 

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

SELECT * FROM Shops WHERE shop_id = '00050';

조작 대상이 되는 레코드 수

- Rows 1개

 

접근 대상 객체와 조작

- PostgreSQL : 'Index Scan' / Oracle : 'INDEX UNIQUE SCAN'

- 인덱스는 일반저긍로 스캔하는 모집합 레코드 수에서 선택되는 레코스 수가 적다면 테이블 풀 스캔보다 빠르게 접근을 수행한다.

-인덱스를 사용할 때 활용되는 B-tree가 모집합의 데이터양에 따라 대수 함수적으로 처리 비용이 늘어나기 때문이다.

 

4. 간단한 테이블 결합의 실행 계획

- SQL 에서 지연이 일어나는 경우는 대부분 결합과 관련된 것이다.

- 결합을 사용하면 실행 계획이 상당히 복잡해지므로, 옵티마이저도 최적의 실행 계획을 세우기 어렵다.

 

SELECT shop_name
    FROM Shops S INNER JOIN Reservations R
    ON S.shop_id = R.shop_id;

- 결합할 때 사용하는 가장 간단한 결합 알고리즘은 Nested Loops이다.

    ㆍ한쪽 테이블을 읽으면서 레코드 하나마다 결합 조건에 맞는 레코드를 다른 쪽 테이블에서 찾는 방식이다.

- 두 번째는 Sort Merge이다.

    ㆍ결합 키(현재 예제에서는 점포ID)로 레코드를 정렬하고, 순차적으로 두 개의 테이블을 결합하는 방식

    ㆍ결합 전에 전처리로(원칙적으로) 정렬을 수행해야 한다.

    ㆍ이때 워킹 메모리 사용

- 세 번째는 Hash이다

    ㆍ이름 그대로 결합 키값을 해시값으로 맵핑하는 방법

    ㆍ해시 테이블 만들어야 하므로, 마찬가지로 메모리 영역을 필요로 한다.

 

객체에 대한 조작의 종류

- PostgreSQL : Nested Loop / Oracle : NESTED LOOPS

- 실행 계획은 일반적으로 트리 구조이다.

- 이때 중첩 단계가 깊을수록 먼저 실행된다.

- 같은 중첩 단계에서는 위에서 아래로 실행된다.

 

5. 실행 계획의 중요성

- 옵티마이저는 완벽하지 않으므로 최후의 방법으로 실행 계획을 수동으로 바꿔주는 방법도 있다.

    ㆍ예를 들어 oracle, MySQL 등이 가지고 있는 힌트 구를 사용하면, SQL 구문에서 옵티마이저에게 강제적으로 명령 가능

 

---

마치며..

- 데이터베이스는 다양한 트레이드오프의 균형을 잡으려는 미들웨어

- 특히 성능적인 관점에서는 데이터를 저속의 저장소(디스크)와 고속의 메모리 중에 어디에 위치시킬지의 트레이드오프가 중요

- 데이터베이스는 갱신보다도 검색과 관련된 것에 비중을 두도록 기본 설정되어 있지만, 실제 시스템에서도 그럴지는 판단이 필요

- 데이터베이스는 SQL을 실행 가능한 절차로 변환하고자 실행 계획을 만듦

- 사실 사용자가 실행 계획을 읽다는 것은 데이터베이스의 이상을 어기는 일이지만, 세상 모든 것이 이상적으로 돌아가는 않음