SQL 레벨업 - 1장 DBMS 아키텍처 (1/2)

2018-10-28

1강 DBMS 아키텍처 개요

쿼리 평가 엔진

쿼리 평가 엔진은 사용자로부터 입력받은 SQL 구문을 분석하고, 어떤 순서로 기억장치의 데이터 접근할지를 결정한다. 이때 결정되는 계획을 ‘실행 계획’이라고 한다. 이러한 실행 계획에 기반을 둬서 데이터에 접근하는 방법을 ‘접근 메서드’라고 부른다.

버퍼 매니저

DBMS는 버퍼라는 특별한 용도로 사용하는 메모리 영역을 확보해둔다. 이 메모리를 관리하는 것이 버퍼 매니저다. 디스크를 관리하는 디스크 용량 매니저와 함께 연동되어 작동한다.

디스크 용량 매니저

데이터베이스는 가장 많은 데이터를 다루는 소프트웨어다. 또한 웹 서버 또는 애플리케이션 서버는 실행되는 동안에만 저장하면 되지만, 데이터베이스는 데이터를 영구적으로 저장해야한다.

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

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

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

리커버리 매니저

시스템에 장애를 대비하여 데이터를 정기적으로 백업하고, 문제가 일어났을 때 복구하는 기능을 수행하는것이 리커버리 매니저.

2강 DBMS와 버퍼

메모리는 한정된 희소 자원이다. 반면 데이터베이스가 메모리에 저장하고자 하는 데이터는 너무 많다. 따라서 데이터를 버퍼에 어떠한 식으로 확보할 것인가에 대해 트레이드오프가 발생한다.

기억장치의 계층

memory_hierarchy

기억장치의 계층

일반적으로 기억장치는 기억 비용에 따라 1차부터 3차까지의 계층으로 분류한다. 기억 비용이란 데이터를 저장하는데 소모되는 비용을 나타낸다.

  • 1차 기억장치
    • 레지스터, 메모리 등
  • 2차 기억장치
    • HDD, CD, DVD, 플래시 메모리 등
  • 3차 기억장치
    • 테이프 등

기억 비용이 저렴하다고 해서 좋은 기억장치가 아니다. 피라미드의 아래 면적이 큰 것은 ‘같은 비용으로 저장할 수 있는 데이터 용량이 많다’를 뜻한다.

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

DBMS와 기억장치의 관계

  • 하드디스크(HDD)

DBMS가 데이터를 저장하는 매체는 대부분 HDD다. 다른 선택지도 있지만 용량, 비용, 성능의 관점에서 대부분 HDD를 사용중.

데이터베이스는 대부분의 시스템에서 범용적으로 사용되는 미들웨어이므로, 어떤 상황에서도 평균적인 수치를 가지는 매체를 선택하는것이 자연스럽다. DBMS가 데이터를 디스크 이외의 장소에 저장하지 않는 뜻은 아니다. 오히려 일반적인 DBMS는 항상 디스크 이외의 장소에도 데이터를 올려놓는다.

  • 메모리

메모리는 디스크에 비해 기억 비용이 굉장히 비싸다. 따라서 하드웨어 1대에 탑재할 수 있는 양이 크지않다. 일반적인 데이터베이스 서버의 경우 탑재되는 메모리 양은 한두 자리 정도이다. 아무리 많아도 100GB가 넘지 않는데, 테라바이트 단위의 용량을 가지는 HDD와 비교하면 매우 작은 크기이다. 따라서 규모 있는 상용 시스템의 데이터베이스 내부의 데이터를 모두 메모리에 올리는 것은 불가능하다.

  • 버퍼를 활용한 속도 향상

DBMS가 일부라도 데이터를 메모리에 올리는 이유는 성능 향상 때문이다. 자주 접근하는 데이터를 메모리 위에 올려둔다면, 같은 SQL구문을 실행한다고 해도 디스크에서 데이터를 가져올 필요 없이 메모리에서 바로 데이터를 빠르게 검색할 수 있다.

버퍼

buffer

디스크 접근을 줄일 수 있다면 큰 폭의 성능 향상이 가능하다. 일반적인 SQL 구문의 실행 시간 대부분을 저장소 I/O에 사용하기 때문이다.

성능 향상을 목적으로 데이터를 저장하는 메모리를 버퍼 또는 캐시 라고 한다. 사용자와 저장소 사이에서 SQL 구문의 디스크 접근을 줄여주는 역할을 한다. 주로 물리적인 매체로 메모리가 사용되는 경우가 많다. 따라서 하드디스크 위에있는 데이터에 접근하는 것보다 훨씬 빠르다.

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

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

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

  • 데이터 캐시
  • 로그 버퍼

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

MySQL의 경우 데이터 캐시는 버퍼 풀로 명칭한다, 로그 버퍼는 그대로

  • 데이터 캐시

데이터 캐시는 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 메모리 영역이다. SELECT 구문의 결과 값이 모두 데이터 캐시에 있다면 디스크와 같은 저속 저장소에 접근하지 않기 때문에 빠르게 응답할 수 있다.

반면에 데이터가 캐시에 없다면 디스크까지 내려가야 하기때문에 응답 속도가 느려진다.

  • 로그 버퍼

로그 버퍼는 갱신 처리(INSERT, DELETE, UPDATE, MERGE)와 관련 있다. DBMS는 갱신과 관련된 SQL구문을 사용자로부터 받으면, 곧바로 저장소에 있는 데이터를 변경하지 않는다. 일단 로그 버퍼 위에 변경 정보를 보내고 이후에 디스크에 변경을 수행한다.

이처럼 데이터베이스의 갱신 처리는 SQL 구문의 실행 시점과 저장소에 갱신하는 시점에 차이가 있는 비동기 처리다.

SQL구문을 실행할 때 단순히 저장소 상의 파일을 바로 변경하는 편이 간단하다. 하지만 DBMS가 이러한 시점의 차이를 두는 이유는 성능을 높이기 위해서다. 저장소는 검색 뿐만이 아니라 갱신을 할때도 상당한 시간이 소모 된다. 따라서 저장소 변경이 끝날 때까지 기다리면 사용자는 장기간 대기하게 된다. 따라서 한 번 메모리에 갱신 저보를 받은 시점에서 사용자에게는 해당 SQL구문이 ‘끝났다’라고 통지하고, 내부적으로는 관련된 처리를 계속 수행한다.

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

  • 휘발성

메모리에는 데이터의 영속성이 없다. 하드웨어의 전원을 꺼버리ㅓ면 메모리 위에 올라가 있는 모든 데이터가 사라진다.

DBMS를 껏다 켜면 버퍼 위의 모든 데이터가 사라진다. 따라서 DBMS에 어떤 장애가 발생해서 프로세스다운이 일어나면, 메모리 위에 있는 모든 데이터가 날아간다.

때문에 영속성이 보장되지 않는 이상 기능적으로 디스크를 완전히 대체하는것은 불가능하다.

  • 휘발성의 문제점

가장 큰 문제점은 장애로 인해 메모리에 있던 데이터가 모두 사라져 데이터 부정합을 발생시키는것이다. 데이터 캐시 라면 장애로 인해 메모리 위의 데이터가 사라져도 디스크에 원본 데이터가 남아있기 때문에 문제 없다. 따라서 시간이 더 걸리지만 결과에는 문제없다.

하지만 로그 버퍼위에 존재하는 데이터가 로그 파일에 반영 되기전에 장애가 발생한다면 해당 데이터가 완전히 사라져서 복구조차 불가능해 진다. 예를 들면 은행 입출금 또는 카드 인출이 데이터베이스에 반영이 안될 수 있다는 것이다.

이를 회피하기 위해 DBMS는 커밋 시점에 반드시 갱신 정보를 로그 파일(영속적인 저장소에 존재)에 씀으로써, 장애가 발생해도 정합성을 유지한다. 커밋 이란 개신 처리를 ‘확정’하는 것이며 DBMS는 커밋된 데이터를 영속화 한다.

반대로 말하면 커밋 때는 반드시 디스크에 동기 접근이 일어난다. 여기서 다시 트레이드오프가 나타난다. 디스크에 동기 처리를 한다면 데이터 정합성이 높아지지만 성능이 낮아지게 된다.

추가적인 메모리 영역 ‘워킹 메모리’

  • 언제 사용될까?

정렬 또는 해시 관련 처리에 사용되는 작업용 영역으로 워킹 메모리 라고 부른다. 정렬은 ORDER BY 구, 집합 연산 등의 기능을 사용할때 실행된다. 반면 해시는 주로 테이블 등의 결합에서 해시결합이 사용되는때 실행된다.

오라클의 경우 PGA라 명칭하고, MySQL은 정렬 버퍼라고 한다.

작업용 메모리 영역은 SQL에서 정렬 또는 해시가 필요한 때 사용되고, 종료되면 해제되는 임시 영역이며, 일반적으로 데이터 캐시와 로그 버퍼와는 다른 영역으로 관리되는 경우가 많다.

워킹메모리가 성능적으로 중요한 이유는, 만약 워킹메모리의 크기가 다루려는 데이터의 크기보다 작다면 DBMS가 저장소를 사용하기 때문이다.

DBMS는 워킹메모리가 부족할때 사용하는 임시적인 영역을 가지고 있다. 이러한 일시 영역들은 저장소 위에 있으므로 당연히 접근 속도가 느리다.

오라클의 경우 임시 테이블 스페이스, MsSQL의 경우 TEMPDB