SQL 레벨업 01

 

DBMS의 개략적인 구조

1. 쿼리 평가 엔진

- Pareser + Optimizer + 플랜 실행 + 연산 평가

- 입력받은 SQL 구문을 분석하고, 어떤 순서로 기억장치의 데이터에 접근할지 결정해 실행 계획을 세움

2. 버퍼 매니저

- DBMS의 버퍼를 관리한다.

3. 디스크 용량 매니저

- 어디에 어떻게 데이터를 저장할지를 관리한다.

- 디스크의 읽고 쓰기를 제어해 데이터를 영구적으로 저장하는 것을 보조한다.

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

- DBMS의 내부의 추상화된 실행 단위인 트랜잭션을 관리해 정합성을 유지하고,

- 필요하다면 데이터에 락을 걸어 다른 사람의 요청을 대기시킨다.

5. 리커버리 매니저

- 장애, 혹은 데이터가 손상되었을 때 이를 복구하는 기능을 제공한다.

- 백업, 복구 등 기능을 제공한다.

 

 

버퍼

DBMS가 데이터를 유지하게 사용하기 위한 메모리 공간. 크게 2가지가 있다. 가변적으로 사이즈 조절도 가능하다.

데이터 캐시

- MySQL에서 Buffer Pool이라고 불린다.

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

- SQL 구문의 결과가 메모리에 있다면 HDD까지 가지 않고 바로 결과를 반환할 수 있음.

- 일반적으로 로그 버퍼보다 기본 사이즈가 크게 설정해서 사용하지만 DBMS에 따라서 동적으로 크기가 가변 하거나 설정할 수 있다.

로그 버퍼

- MySQL에선 로그 버퍼라고 불린다.

- DML을 수행할 때 바로 HDD의 데이터를 조작하는 것이 아니라 로그 버퍼 위에 변경정보를 보낸다.

- 즉 SQL 구문 실행 시점과 저장소의 데이터 갱신 시점이 차이가 있는 비동기 처리를 지원한다.

- 갱신 또한 굉장히 비싼 작업이다. 갱신 중엔 사용-자가 갱신이 끝날 때까지 장시간 대기할 수 있다.

 

서비스 중 장애가 생겨서 버퍼의 데이터가 휘발된다면?

- DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일로 영속적인 저장 공간에 저장한다.

- 이를 통해 장애가 생겨서 버퍼 데이터가 휘발되어도 정합성을 유지할 수 있도록 한다.

- 즉 커밋은 갱신 처리를 확정하는 행위로 커밋된 데이터는 DBMS에 의해 영속된다라고 말할 수 있다.

 

결국 데이터베이스는 저장소(HDD)의 느림을 어떻게 보완할 것인가를 해결하면서 발전해왔다고 볼 수 있다.

 

워킹 메모리

- 정렬, 해시 관련 처리에 사용되는 작업 영역

- SQL에서 정렬 및 해시가 필요할 때 사용되고 종료되면 해제된다.

- 즉 워킹 메모리 공간이 다루려는 데이터 영역보다 작다면 디스크 스왑이 발생해서 성능 저하의 원인이 된다.

카탈로그 매니저

- 옵티마이저가 실행 계획을 세울 때 중요한 정보를 제공한다.

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

- 기본적으로 다음과 같은 정보들이 있다.

- 각 테이블의 레코드 수

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

- 필드의 카디널 리티

- 필드 값의 히스토그램

- 필드 내부에 있는 NULL 수

- 인덱스 정보

- 옵티마이저에게 실행 계획을 맡기는 경우 최적의 성능을 기대하기 어려울 수 있다.

- 옵티마이저는 즉 카탈로그 매니저에서 테이블의 정보를 기반으로 입력된 쿼리를 가장 효율적으로 실행할 수 있는 실행 계획을 세운다.

- 카탈로그 매니저는 DBMS에 따라서 다르지만 일반적으로 일정 주기를 가지고 데이터를 갱신한다.