DBMS와 버퍼

DBMS와 버퍼

---

기억장치의 분류

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

 

DBMS와 기억장치의 관계

---

DBMS는 데이터 저장을 목적으로하는 미들웨어이기 때문에 기억장치와 떨어뜨릴 수 없는 관계이다.

하디드스크(HDD)

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

메모리

• 메모리는 디스크에 비해 기억 비용이 비싸기 때문에, 하드웨어 1대에 탑재할 수 있는 양이 크지 않다.

• DBMS는 항상 디스크 이외의 장소에도 데이터를 올려 놓는데, 바로 1차 계층의 기억장치 메모리에 올려놓는다.

버퍼를 활용한 속도 향상

• DBMS가 일부라도 데이터를 메모리에 올리는 것은 성능 향상 때문이다. 한마디로 SQL 구문의 실행 속도를 빠르게 만들기 위함이다.

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

디스크 접근을 줄일 수 있다면 성능이 큰폭으로 향상 시킬 수 있다. 이는 SQL 구문의 실행 시간 대부분을 저장소 I/O(입출력)에 사용하기 때문이다.

 

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

사용자와 저장소 사이에서 SQL 구문의 디스크 접근을 줄여주는 역할을 한다.(하드디스크 위에 있는 데이터에 접근하는 것보다 훨씬 빠르다.)

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

=> 버퍼매니저가 데이터베이스 성능에 굉장히 중요한 영향을 끼친다는 것을 알 수 있다.

 

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

---

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

• 데이터 캐시
• 로그 버퍼

데이터 캐시

• 디스크에 있는 데이터의 일부를 메모리에 유지하기 위해 사용하는 메모리 영역
• 데이터베이스 세계에는 '디스크를 건드리는 자는 불행해진다'라는 오래된 격언이 있음(메모리를 적절히 사용해야 함)

로그버퍼

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

client =>갱신 SQL => 로그버퍼에 쓰임 => Commit => 저장소에 저장

 

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

=> 성능을 향상시키기 위한 방법인데 갱신을 할 때도 상당한 시간이 소모되기 때문에 저장소 변경이 끝날 때까지 기다리면 사용자는 장기간 대기해야 한다. 따라서 사용자에게 해당 SQL 구문이 '끝났다'라고 통지하고, 내부적으로 관련된 처리를 계속 수행하는  것이다.

 

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

---

메모리의 단점

휘발성

• 메모리에는 데이터의 영속성이 없다. 전원을 꺼져버리면 메모리 위에 올라가 있는 모든 데이터가 사라지는데 이러한 성질을 휘발성이라고 한다. (버퍼위의 데이터들이 모두 날아감)
• 영속성이 없는 이상 디스크를 완전히 대체하는 것은 불가능

휘발성의 문제점

• 가장 큰 문제점은 장애가 발생했을 때 메모리에 있던 데이터가 모두 사라져버려 데이터 부정합을 발생시킨다는 점이다.
• 데이터 캐시라면 디스크위에 데이터가 남아있기 때문에 문제가 되지 않지만 로그 버퍼 위에 존재하는 데이터가 로그 파일에 반영되기 전에 장애가 발생해서 사라져 버린다면 복구조차 불가능해 진다.

동기 처리 => 데이터 정합성 o, 성능 x

비동기 처리 => 데이터 정합성 x, 성능 o

 

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

---

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

DBMS의 기본 초기값이이 데이터 캐시에 비해 로그 버퍼가 작은 것을 볼 수 있다.

데이터베이스는 기본적으로 검색을 메인으로 처리한다고 가정하기 때문이다.

검색 처리는 대상 레코드가 수백만 ~ 수천만 건에 달하는 경우가 많지만,

갱신 처리는 많아 봤자 트랜잭션마다 한건 ~ 수만건 정도 밖에 되지 않기 때문이다.

 

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

---

언제 사용될까?

• DBMS는 앞에서 설명했던 2개의 버퍼(데이터 캐시, 로그 버퍼) 외에도, 일반적으로 메모리 영역을 하나 더 가지고 있다.
• 정렬 또는 해시 관련 처리에 사용되는 작업용 영역으로 워킹 메모리(working memory)라고 부른다. 
• 정렬은 Order by, 집합 연산, 윈도우 함수 등에 사용된다.
• 해시는 주로 테이블 등의 결합에서 해시 결합이 사용되는 때 실행된다.

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

이 영역이 성능적으로 중요한 이유는 이 영역이 다루는 데이터양보다 부족해지는 경우가 생기면 DBMS가 저장소를 사용하기 때문이다. (디스크를 사용하기 때문에 성능이 악화된다.)

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

• 에러가 발생하거나 심각한 문제가 생기는 것은 아니지만, 메모리에 작동하고 있을 때는 빠르게 움직이다가, 메모리가 부족해지는 순간 갑자기 느려지는 순간적인 변화가 일어나는 것이 문제이다.
• 자바는 힙(heap) 크기가 부족하면 메모리 부족(out of memory) 오류를 발생시켜 모든 처리를 중단시키지만, 데이터베이스는 그러지 않는다.(비록 느려지는 상황이 발생하더라도 끝까지 처리하겠다... 처리 계속성을 담보하려 하기 때문이다.)

 

(출처 : SQL레벨업)