DBMS와 기억장치의 관계 및 메모리 활용

 

<DBMS와 기억장치의 관계>

기억장치는 기억 비용에 따라 1차~3차 계층으로 분류할 수 있다. 기억 비용이란 '데이터를 저장하는데 소모되는 비용'이다.

 

그림 - 기억장치의 계층

 

그림의 피라미드에서 아래로 갈수록 면적이 커지는 것은 같은 비용으로 저장할 수 있는 데이터 용량이 크다는 것을 나타낸다.

그러나 기억 비용이 낮을수록 데이터 접근 속도가 느려진다.

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

DBMS는 데이터 저장을 목적으로 하는 미들웨어이므로 기억장치와 밀접한 관계가 있다. DBMS가 사용하는 대표적인 기억장치는 HDD(하드디스크), 메모리이다.

용량, 비용, 성능상의 이점때문에 DBMS의 데이터 저장 매체로 HDD가 많이 사용된다.

메모리는 HDD에 비해 기억 비용이 굉장히 비싸기 때문에 대규모 상용 시스템의 모든 데이터를 메모리에 저장하는 것은 불가능하다.

 

<DBMS의 메모리 활용>

DBMS는 HDD와 같은 디스크를 주로 사용하지만 성능 향상을 위해, 즉 SQL 구문 실행 속도 향상을 위해 자주 접근하는 일부 데이터를 메모리에 올려 같은 SQL 구문을 실행하면 빠르게 데이터를 검색할 수 있도록 한다. 일반적인 SQL 구문의 실행 시간의 대부분은 저장소 I/O에 사용되기에 디스크 접근을 줄이는 것은 성능 향상에 큰 도움이 된다.

이렇게 성능 향상을 목적으로 데이터를 저장하고 고속 접근이 가능한 메모리를 버퍼 또는 캐시라 하며 DBMS 구성요소 중 버퍼 매니저가 버퍼에 데이터를 어떻게, 어느 정도의 기간 동안 올릴지를 관리한다.

DBMS의 버퍼 메모리 영역은 쿼리 평가 엔진과 마찬가지로 성능에 아주 중요한 영향을 미친다.

 

- 데이터 캐시와 로그 버퍼

DBMS가 사용하는 버퍼 메모리 영역은 크게 데이터 캐시, 로그 버퍼로 나뉜다. 대부분의 DBMS는 이러한 메모리 영역을 갖고 있으며 크기 변경이 가능하다. 다음 표는 Oracle, PostgreSQL, MySQL의 특정 버전 별 버퍼 메모리 정보이다.

 

표 - DBMS 별 데이터 캐시와 로그 버퍼 메모리

		Oracle 11gR2	PostgreSQL 9.3	MySQL 5.7(InnoDB)
데이터 캐시	명칭	데이터베이스 버퍼 캐시	공유 버퍼	버퍼 풀
	매개변수	DB_CACHE_SIZE	shared_buffers	innodb_buffer_pool_size
	초기값	5MB * CPU 갯수 * 그래뉼 크기(SGA_TARGET이 설정되어 있지 않은 경우 48MB)	128MB	128MB
	설정값 확인	SELECT value FROM v$parameter WHERE name='db_cache_size'	show shared_buffers	SHOW VARIABLES LIKE 'innodb_buffer_pool_size'
	비고	SGA 내부에 확보	-	-
로그 버퍼	명칭	REDO 로그 버퍼	트랜잭션 로그 버퍼	로그 버퍼
	매개변수	LOG_BUFFER	wal_buffers	innodb_log_buffer_size
	초기값	512KB 또는 128KB * CPU_COUNT 중 큰 값	64KB	8MB
	설정값 확인	SELECT value FROM v$parameter WHERE name='log_buffer'	show wal_buffers	SHOW VARIABLES LIKE 'innodb_log_buffer_size'
	비고	-	-	InnoDB 엔진 사용 시에만 적용

 

DBMS에서 사용하는 버퍼 메모리 데이터 캐시, 로그 버퍼에 대해 좀 더 알아보자.

데이터 캐시는 디스크의 일부 데이터를 메모리에 저장하기 위해 사용하는 영역이다. 만약 어떤 쿼리의 데이터가 모두 데이터 캐시에 있으면 디스크에 접근하지 않고 수행되어 아주 빠르게 응답된다.

 

로그 버퍼는 INSERT, DELETE, UPDATE와 같은 갱신 처리와 관련이 있다. DBMS는 갱신 SQL 구문을 받으면 바로 저장소의 데이터를 변경하는게 아니라 일단 로그 버퍼에 변경 정보를 보내고 그 이후 COMMIT 시 로그 버퍼 메모리로부터 정보를 가져와 디스크에 변경을 수행한다. 이렇게 데이터베이스의 갱신은 SQL 구문의 실행 시점과 실제 저장소에 갱신되는 시점에 차이가 있는 비동기 방식으로 처리된다.

 

- 로그 버퍼는 왜 사용되는가?

단편적으로 생각해보면 갱신 SQL 구문을 실행할 때 바로 저장소를 변경하는 것이 간단하다. 그럼에도 불구하고 DBMS가 비동기 처리를 하는 이유는 성능을 높이기 위해서이다. 동기식으로 처리하면 저장소 변경이 완료될때까지 DBMS 사용자는 다른 작업을 하지 못하고 대기해야한다. 따라서 COMMIT 명령에 의해 로그 버퍼에서 갱신 정보를 받은 시점에 사용자에게 완료 통지를 하고 DBMS 내부에서 관련된 처리를 수행하는 것이다.

 

<메모리의 휘발성>

일반적인 메모리는 전원 공급 없이 데이터를 영속적으로 저장하지 못하므로 DB 서버를 재기동하거나 어떠한 장애로 서버가 죽으면 버퍼 메모리의 모든 데이터가 삭제된다. 이러한 메모리의 휘발성때문에 디스크를 완전히 대체하는 것은 불가능하다.

휘발성의 가장 큰 문제점은 로그 버퍼 메모리의 데이터가 디스크에 반영되기 전에 날아가 데이터 부정합을 발생시킬 수 있다는 것이다. 이는 DBMS가 갱신을 비동기로 처리하는 이상 언제든 발생할 수 있는 문제이다. 따라서 이를 회피하기 위해 DBMS는 commit 시점에 반드시 갱신 정보를 영속적인 저장소에 존재하는 로그 파일에 씀으로써 장애가 발생해도 정합성을 유지할 수 있게 한다.

 

✏️ 참고
일반적으로 commit 시점에는 무조건 로그 버퍼에서 디스크로 쓰이지만 DBMS에 따라 설정을 변경할수도 있다.
예를 들어 PostgreSQL은 '비동기 commit'이라는 설정이 있어 commit 시점에도 로그 버퍼에서 디스크에 쓰지 않을 수 있다.
이는 데이터의 정합성, 신뢰성을 포기하고 성능을 추구하는 극단적인 트레이드 오프 사례이다.

 

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

일반적으로 DBMS의 로그 버퍼는 데이터 캐시에 비해 초기값이 굉장히 작다. 이는 데이터베이스는 기본적으로 검색(쿼리)을 메인으로 처리한다고 가정하기 때문에 기본적으로 그렇게 할당이 되어있는 것이다.

검색 처리를 할때는 검색 대상 레코드가 수천만건에 달하는 경우도 많지만 갱신 처리를 할때는 갱신 대상이 많아봤자 트랜잭션당 한 건 ~ 수만 건 정도이다.

실제로 많은 DBMS가 메모리에 여유가 있다면 검색에 사용되는 데이터 캐시를 가능한 크게 할당할 것을 추천하고 있다.

만약 운영하는 시스템이 검색에 비해 갱신이 많다면 초기 설정을 그대로 사용하는 것 보다는 로그 버퍼의 크기를 늘려주는 튜닝을 고려해봐야 한다.

또한 운영중인 서비스의 데이터베이스의 로그 버퍼가 크게 잡혀있다면 갱신 처리를 우선 고려한 설계임을, 반대로 데이터 캐시가 크게 잡혀있다면 검색 처리가 중심인 것을 알 수 있다.

 

<워킹 메모리>

DBMS는 데이터 캐시, 로그 버퍼 외에도 워킹 메모리라는 메모리 영역을 하나 더 갖는다. 이는 정렬, 해시 관련 처리에 사용되는 영역이다.

정렬은 ORDER BY, 집합 연산 등의 기능을 사용할 때 실행되고 해시는 주로 테이블의 결합에서 해시 결합이 사용될 때, GROUP BY를 사용할 때 실행된다.

 

표 - DBMS 별 워킹 메모리

DBMS	명칭	매개변수	기본값
Oracle 11g R2	PGA(Program Global Area)	PGA_AGGREGATE_TARGET	10MB 또는 SGA 크기의 20% 중 큰 값
PostgreSQL 9.3	워크 버퍼	work_mem	8MB
MySQL 5.7	정렬 버퍼	sort_buffer_size	256KB

 

워킹 메모리는 정렬 또는 해시가 필요할때 사용되고 종료되면 해제되는 임시 영역이다. 만약 이 영역이 다루려는 데이터 양보다 작아 부족해지면 대부분의 DBMS가 저장소를 사용하게 된다. 그리고 많은 DBMS는 저장소 안에 워킹 메모리가 부족할때 사용하는 임시 영역을 갖고 있다. 해당 영역은 다음과 같은 이름으로 부른다.

 

• Oracle: TEMP Tablespace
• Microsoft SQL Server: TEMPDB
• PostgreSQL: pgsql_tmp

 

워킹 메모리는 공유해서 사용되므로 여러 개의 SQL 구문들을 동시에 실행하면 메모리가 넘쳐 위의 임시 영역을 사용하게 된다. 임시 영역은 메모리가 아닌 저장소에 있으므로 처리 속도 변화, 저하가 발생하지만 처리를 멈추거나 에러를 발생시키지는 않는다.

 

DBMS의 이러한 메커니즘들은 메모리가 부족하더라도 전달받은 SQL 구문을 정상적으로 처리하고, 데이터베이스 데이터의 처리 계속성을 담보하게 해준다.

 

📚 참고 서적

• SQL 레벨업