데이터베이스 관리 시스템의 아키텍처(DBMS Architecture)

데이터베이스 관리 시스템 아키텍처 

출처: https://velog.io/@tastestar/DBMS-아키텍처

쿼리 평가 엔진

쿼리 평가 엔진은 사용자로부터 입력받은 SQL 구문을 분석하여 어떤 순서로 기억장치의 데이터에 접근할지 결정한다. 이때 결정되는 계획을 '실행 계획'이라고 한다. 이러한 실행 계획에 기반을 둬 데이터에 접근하는 방법을 '접근 메서드'라 한다. 쿼리 평가 엔진은 계획을 세우고 실행하는 DBMS의 핵심 기능을 담당하는 모듈이다.

 

디스크 공간 매니저

DBMS에서 가장 낮은 Layer에서 디스크의 공간을 관리한다. 상위 컴포넌트에서 페이지를 할당하거나 할당 해제, 페이지를 읽거나 쓰는 요청을 받아서 처리한다. 디스크 공간 매니저는 성능을 위해서 페이지들을 최대한 순차적으로 배치한다. 왜냐하면 seek time이나 rotation 지연을 최대한 줄이기 위함이다.

데이터베이스 장애(failure)와 회복(recovery) 파트에서 데이터베이스의 저장 연산에 대해 잠깐 다룬 적이 있다. 그중 페이지와 블록은 같은 뜻으로 이해해도 무방하다. 기본적으로 데이터 이동이 페이지(블록) 단위로 수행된다.

 

버퍼 매니저

디스크에서 데이터를 읽어오는 것은 메모리에 접근하는 것보다 비용이 높다. 따라서 효과적으로 메모리-디스크 데이터 전송을 위해서는 버퍼 관리가 필요하다. 따라서 DBMS는 버퍼라는 메모리 영역을 확보해두며 이 메모리 영역을 관리하는 것이 버퍼 매니저다.

출처: https://courses.cs.washington.edu

위 그림은 페이지 버퍼링 개요를 나타낸다. 우선 Pool에서 page를 저장할 frame을 선택한다. 그중 free frame이 있으면 그 free fame을 선택한다. 만약에 없는 경우에는 교체 정책에 따라서 희생 frame을 unpin 하고 결정한다. 그 후 page를 disk에서 읽어 frame에 저장한다. 

 

pin은  page를 사용하는 사용자가 있음을 표시하기 위해 사용한다. 만약 사용자가 여러 명이라면 pin_count를 증가시키며 0인 경우에 교체 대상이 될 수 있다. 사용자는 page 사용이 끝나면 page에 대한 unpin을 부른다. 만약 메모리 상에 업데이트된 페이지가 있을 경우 dirty flag를 설정한다. 

만약에 읽을 page의 목록이 예측이 된다면 성능 향상을 위해서 사전에 미리 전부 올려두는 기능을 제공한다.

교체 정책은 LRU, MRU, 2Q, LRU-2, ARC와 같은 다양한 페이지 교체 알고리즘이 존재하면 DBMS 버퍼 관리의 두 가지 흐름을 보며 해당 내용을 톺아보는 것도 좋을 듯싶다.

 

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

많은 사람들이 동시에 데이터베이스에 접근해서 사용하는데,  이때 각 처리는 DBMS의 내부에서 트랜잭션이라는 단위로 관리된다. 이러한 트랜잭션의 정합성을 유지하면서 실행시키고, 필요한 경우 데이터에 락을 걸어 다른 사람의 요청을 대기시키는 것을 트랜잭션 매니저와 락 매니저의 역할이다.

transaction management module에는 concureency control module과 recovery control module이 존재한다. 이 중 트랜잭션 매니저와 락 매니저는 concurrency control module을 리커버리 매니저는 recovery control module을 의미하는 것 같다. 

트랜잭션의 병행 수행(concurrency)과 병행 제어(concurrency control)를 보며 동시 실행 제어 모듈의 역할을 다시 한번 상기해보는 것도 좋을 것 같다.

 

리커버리 매니저

DBMS가 저장하고 있는 데이터 중에는 절대 잃어버리면 안 되는 데이터가 있다.  장애가 발생했을 때 중요한 데이터는 정기적으로 백업하고, 문제가 일어났을 때 복구를 해줘야 하는 데 이 기능을 수행하는 것이 리커버리 매니저이다.

 

데이터베이스 장애(failure)와 회복(recovery)을 통해 회복 파트에 대해서 상기해보자. 네이버 D2 DBMS는 어떻게 트랜잭션을 관리할까? 에 따르면 UNDO 복구와 REDO 복구는 버퍼 관리 정책에 의존적이라는데 다음에 한번 제대로 다뤄봐야겠다.