database.sarang.net
UserID
Passwd
Database
DBMS
MySQL
PostgreSQL
Firebird
Oracle
Informix
Sybase
MS-SQL
DB2
Cache
CUBRID
LDAP
ㆍALTIBASE
Tibero
DB 문서들
스터디
Community
공지사항
자유게시판
구인|구직
DSN 갤러리
도움주신분들
Admin
운영게시판
최근게시물
ALTIBASE Tutorials 21 게시물 읽기
 News | Q&A | Columns | Tutorials | Devel | Files | Links
No. 21
2회 메인 메모리 DBMS 기술
작성자
최한열(검은호랑이)
작성일
2005-04-21 13:33
조회수
14,622

1회: 메인 메모리 DBMS의 등장 배경과 개요
2회: 메인 메모리 DBMS 기술
3회: 메인 메모리 DBMS의 안정성과 이중화
4회: 메인 메모리 DBMS 현황 및 전망

메인 메모리 DBMS 기술

메인 메모리 DBMS도 기존 디스크 기반 DBMS와 동일하게 데이터를 체계적으로 관리하고 응용 프로그램을 쉽게 개발하도록 지원하고자 하는 목적으로 개발된 DBMS이기 때문에 적용된 전반적인 기술 역시 거의 동일하다. 다만, 메인 메모리 DBMS는 DB 전체를 메모리에 상주시키고 고속으로 트랜잭션을 처리하는 것에 최우선 목표를 두고 있기 때문에, 요소기술의 경우 디스크 기반 DBMS의 그것과는 어느 정도 차이가 있다.
DBMS의 기술은 크게 인터페이스 기술, 질의처리 기술, 자료저장관리 기술, 유틸리티 기술 등으로 구분할 수 있다. DBMS 인터페이스 기술은 대부분 산업 표준으로 정의되어 있고 유틸리티 기술은 DBMS 기술 자체를 특정지울 수 없으므로 여기에서는 생략하기로 한다. 따라서 질의처리 기술, 자료저장관리 기술, 그리고 기타 기술에 있어서 메인 메모리 DBMS가 채택하고 있는 일반적인 기술 그리고 디스크 기반 DBMS와는 차별화된 기술에 관하여 살펴보기로 한다. 여기서 소개하고자 하는 기술들은 필자가 메모리 DBMS를 개발하는 과정에서 연구하거나 실제 적용한 기술들이다.

질의 처리 과정

DBMS의 일반적인 질의 처리(query processing) 과정은 크게 SQL 문장의 파싱(parsing), 질의 검증(validation), 질의 최적화(optimization), 바인딩(binding), 질의 실행(execution)의 단계를 거친다.
SQL 문장의 직접-실행(direct execution)의 경우는 위의 전 과정을 SQL 문장마다 거치게 되는데 반해, 준비-실행(prepare execution)의 경우는 두 단계로 나누어 처리하게 된다. 준비 단계는 파싱, 검증, 최적화로 이루어지며, 반복적으로 수행되는 실행 단계는 바인딩, 실행으로 이루어진다. 따라서 동일한 SQL 문장을 반복하여 실행하는 응용에 있어서는 직접-실행 방식보다는 준비-실행 방식이 훨씬 효과적이다. 왜냐하면 전자는 SQL 문장을 번역하고 실행하는 과정을 매번 거쳐야 하지만, 후자는 SQL 문장을 한번만 번역하고 번역한 결과(plan tree)를 이용해 반복하여 수행하기 때문이다.
<그림 1>은 질의 처리 흐름을 나타내는 그림으로, 질의를 처리하는 각각의 단계를 설명하면 아래와 같다.
파싱 단계는 주어진 SQL 문장이 적합한 구문인지를 검사하는 구문(syntax) 분석을 수행한다. 파싱 단계의 입력은 SQL 문장이 되며, 출력은 파스 트리(parse tree)가 생성된다.
검증 단계는 파스 트리(parse tree)가 실행 가능한 지를 검사하는 의미(semantic) 검사를 수행하는 단계이다. 의미 검사란 주어진 SQL 문장이 구문상으로는 문제가 되지 않지만 질의 자체가 의미 없는 것인지를 체크하는 것이다. 검증 단계에서는 크게 다음과 같은 처리를 수행하게 된다.

ㆍSemantic Check

ㆍPre-Validation : Created View 또는 In-line View에 대하여 parsing을 수행하고 이를 위한 parse tree를 구성한다.

ㆍ부가 정보 지정 : 질의 처리에 필요한 부가 정보를 지정해 줌으로써 parse tree를 완성한다. 위와 같은 처리 과정을 통해, Parsing 과정에 생성한 구문만을 해석해 놓은 parse tree를, meta 정보를 이용하여 정보가 있는 parse tree로 완성하게 된다.

최적화 단계는 파싱, 검증 과정을 거쳐 생성된 파스 트리(parse tree)를 이용하여 physical operator(죠인, 셀렉션 같은 내부 연산자)의 흐름을 나타내는 실행 계획인 플랜 트리(plan tree)를 생성하는 단계이다. 물론 이 단계에서는 질의 처리 비용을 최소화 하는 것이 주 목적이다.
바인딩 단계는 질의 실행의 단계로 실행 단계를 수행하기 전에, 호스트 변수를 포함하고 있는 SQL statement에 실제 값을 대체시키는 단계이다.
실행 단계는 질의 실행의 마지막 단계로 파싱, 검증, 최적화, 바인딩을 거쳐 완성된 plan tree를 직접 수행하는 것으로서, plan tree의 각 노드를 방문하면서 조인 연산, 프로젝션 연산, 정렬(sorting) 등을 수행하여 주어진 SQL에 대한 결과를 구하게 되는 것이다.

<그림 1> 질의 처리 흐름도
xEdit Image

질의 최적화 기술

SQL 질의 처리 단계에 있어서 가장 중요한 단계는 질의 최적화 단계이다. 이 단계를 얼마나 잘 지원하느냐에 따라 해당 DBMS의 질의 처리 성능을 좌우하게 된다고 해도 과언이 아니다. 질의 최적화는 궁극적으로 질의를 처리하는 과정에서 디스크 I/O, CPU 사용, 테이블 접근 회수, 중간 결과 크기 등을 최소화 하는 법을 만들어 내기 때문이다.
일반적으로 질의 최적화는 비용 기반(cost-based)과 규칙 기반(rule-based) 방법이 있다. 비용 기반 최적화란 주어진 SQL 문장을 처리하는데 있어서 각각의 연산에 대한 시간비용을 계산하여 가장 비용이 적게 드는 방법으로 plan tree를 생성하는 과정이고, 규칙 기반 최적화는 정해진 내부 최적화 규칙에 의해 plan tree를 생성하는 방법이다. 전자는 보다 최적화된 plan tree를 만들어 낼 수 있지만 비용을 계산하는데 시간이 많이 들고 알고리즘도 복잡하다. 후자는 정해진 규칙대로 plan tree를 생성하므로 그 과정이 단순하지만 비효율적인 plan tree가 생성되는 경우가 발생할 수 있다.
메인 메모리 DBMS에서 사용자의 질의 처리 시, 비용 기반으로 최적화된 데이터 접근 경로를 계산하기 위한 비용이 디스크 기반 DBMS 보다 상대적으로 적다. 또한 질의 변형(query transformation)을 비롯한 질의 최적화 알고리즘은 메모리 주소공간에 최적화된 기법이 적용된다. 이는 질의 최적화 시간을 최소화 시키며, 실제 데이터 접근 속도를 향상시킴으로써 월등한 성능 상의 차이를 가져온다. 따라서 메인 메모리 DBMS는 비용 기반 및 규칙 기반의 최적화 기법을 동시에 사용하는 것이 효과적이다.
질의 최적화의 개략적인 시스템 구조는 <그림 2>와 같다.

<그림 2> Optimizer의 시스템 구조
xEdit Image

질의 최적화는 <그림 2>와 같이 그래프 관리자, 플랜 트리 관리자, 서술(predicate) 관리자로 구분한다. 각 관리자의 역할은 다음과 같다.

ㆍ그래프 관리자 : 주어진 파스 트리를 이용해 그래프를 생성하고, 각 그래프에 대한 최적화를 수행한다.

ㆍ플랜 트리 관리자 : 그래프 관리자에 의해 생성된 그래프를 이용해 플랜 트리를 생성한다.

ㆍ서술 관리자 : 그래프 관리자 및 플랜 트리 관리자가 공통적으로 사용하는 모듈로, 산술식(예, i1, i1 + 1)과 서술식(예, i1 = i2)을 관리한다. 즉, 그래프 관리자 및 플랜트 관리자는 서술 관리자를 통해 산술식 및 서술식에 대한 부가 정보를 이용 및 설정을 하게 된다.

메타 테이블 캐싱

질의를 처리하면서 내부적으로 가장 많이 접근하는 테이블은 메타 테이블이다. 메타 테이블은 데이터베이스의 정보 즉, 사용자 정의 테이블, 사용자, 그리고 기타 데이터베이스 관련 정보를 포함하는 DBMS 내부 테이블이라 할 수 있다. 이 메타 테이블을 DBMS의 질의 처리기와 자료저장 관리기가 수시로 참조하게 된다. 따라서 메타 테이블에 대한 접근 성능을 극대화할 필요성이 있는데, 이를 위해 디스크 기반 DBMS는 메타 테이블을 공유 메모리 영역에 상주시켜(캐싱하여) 성능 향상을 꾀하고 있다.
메인 메모리 DBMS는 어차피 메타 테이블을 포함하여 모든 DB를 메인 메모리에 상주시켜 처리하므로 이미 메타 테이블을 메모리에 캐싱해 두고 있다고 볼 수 있다. 그러나 일부 메인 메모리 DBMS는 이에 만족하지 않고 보다 더 메타 테이블의 접근 성능을 높이기 위한 기술들을 적용하고 있다. DBMS 내부 모듈 중 질의처리기가 메타 테이블을 가장 많이 접근한다. 따라서 질의 처리기는 메타 테이블을 일반 테이블과 동일한 방식으로 접근하는 대신에 질의처리에 효과를 발휘할 수 있도록 메타 테이블을 내부 구조에 맞게 캐싱하여 관리하는 기술을 사용한다.

투플 셋 방식 질의 처리

기존의 질의 처리 방법이 대부분 파이프라인(Pipelining) 질의 처리 방법을 사용하고 있는데 반해, 메인 메모리 DBMS는 메모리 상주의 이점을 최대한 살린 투풀 셋(Tuple-set) 질의 처리 방식을 사용하기도 한다.
파이프라인 질의 처리 방법은 하위의 플랜노드의 연산 결과를 임시 테이블로 만들어서 이 결과를 상위 플랜노드로 전달하는 방식을 취하는 것이다. "SELECT T1.I1, T2.I2 FROM T1, T2;" SQL을 처리한다고 가정할 때, <그림 3>처럼 최하위 두 개의 노드(SCAN)는 T1, T2를 각각 스캔 처리하여 스캔 결과를 임시 파일로 만들고 이 결과를 상위 플랜 노드(JOIN)에 전달한다. JOIN 플랜노드는 입력 받은 두 개의 테이블을 조건에 따라 조인 연산을 수행하여 결과로 한 개의 임시 테이블을 만들어 상위 노드(PROJ)에 전달한다. 최종적으로 PROJ 노드는 입력 받은 임시테이블로부터 해당 컬럼만 프로젝션하여 결과를 낸다. 파이프라인 질의 처리 방법은 구현하기는 쉽지만 다음과 같은 문제가 있다.

- 임시테이블을 생성하고 등록하는 비용이 든다.
- 최악의 경우 임시테이블 크기의 메모리 공간을 차지 한다.
- 잦은 메모리 복사가 성능에 장애가 될 수 있다.

<그림 3> 파이프라인 질의 처리 예제
xEdit Image

Row Pointer-based 질의 처리 기법이라고도 하는 투풀 셋 질의처리 방법은 plan tree의 하위 노드부터 방문하며 처리하는 것은 파이프라인 질의 처리 방식과 동일하지만, 다음과 같은 점에서 차이가 있다.

- 하위의 플랜노드는 상위 노드가 어떤 일을 수행하는지 고려할 필요가 없이, 자신의 일만 수행한다.
- 각각의 플랜노드의 연산 결과를 임시 테이블로 만들지 않는다.
- 투풀 셋이라는 자료구조에 연산결과에 대한 조건과 이에 해당하는 Row에 대한 포인터 만을 저장한다.

이 질의 처리 방식은 다음과 같은 특징이 있다.

- 고난이도의 구현 기술을 요구한다.
- 임시 테이블을 만들지 않으므로 메모리가 절약된다.
- 플랜노드 연산 결과가 Row에 대한 포인터만을 유지하므로 메모리 복사가 현저히 줄어든다.
- 따라서 질의를 빠르게 처리할 수 있다.

<그림 4> 투플 셋 질의 처리 예제
xEdit Image

메모리 관리 기술

데이터베이스를 메인 메모리에 상주시킨다고 하면 언뜻 메모리를 과다하게 사용할 것이라는 생각이 들게 한다. 물론 메모리 DBMS가 데이터베이스를 위한 대용량의 메모리를 필요로 하기는 하나, 메모리의 효율적인 관리 여하에 따라 현격한 성능의 차이를 보일 수 있다. 따라서 향상된 성능을 위해서는 메인 메모리에 최적화된 데이터베이스 구조의 설계 및 관리 방법의 적용이 필수적이다.
데이터베이스와 같은 시스템 소프트웨어는 단순히 메모리를 할당(malloc)하고 값을 지정(memset)하는 연산만으로도 성능에 큰 영향을 미칠 수 있다. 따라서 메모리 풀을 이용한 메모리 관리 모듈을 자체적으로 설계하고 구현하는 것이 매우 바람직하다. 또한 메인 메모리에 최적화된 저장 단위로 데이터 페이지를 구성하고 각 페이지의 연계성을 극대화함으로써 데이터베이스를 효율적으로 저장하고 관리해야 한다.
질의 처리기는 질의 처리 시 필요한 임시 공간(temporary storage)을 효율적으로 관리하기 위해 실행 중 불필요한 메모리 자원 할당과 반납에 따른 성능 저해 요소를 최소화해야 한다. 실제 메모리 DB를 운영하다 보면 특정 테이블에 필요한 메모리 공간보다 더 많은 양의 메모리를 차지하는 경우가 있다. 이는 대량의 데이터가 특정 테이블에 삽입된 후 변경 및 삭제가 빈번하게 이루어질 때 주로 발생하는데, 해당 테이블에서 필요 없는 메모리를 시스템으로 반환할 수 있다면 보다 효율적으로 메모리를 사용할 수 있다. 테이블 압축(table compaction)이라는 이 기술을 적용하면, 테이블 연산에 따른 메모리의 불필요한 메모리 낭비를 방지할 수 있다.
메인 메모리 내의 데이터베이스 공간은 영구 공간(persistent space)과 임시 공간(temporary space)으로 구분된다. 영구 공간은 실제 테이블과 메타 정보에 관한 데이터를 저장하고 있는데, 디스크에 존재하는 백업 데이터베이스 내용을 반영하고 있다. 임시 공간은 색인 데이터와 질의연산 중에 파생되는 임시 테이블들이 놓이는 장소로, 디스크에 위치한 백업 데이터베이스에는 반영되지 않고 DBMS 서버가 종료되면 사라지는 공간이다. 색인 데이터는 백업 데이터베이스에 저장되지 않기 때문에 DBMS 서버가 실행되는 초기에 시스템 카탈로그에서 색인 정보를 구하여 임시공간에 색인을 빠르게 생성한다. 색인을 백업 데이터베이스에 저장하지 않음으로써 서버 수행도중 색인 변경에 대하여 로깅할 필요가 없기 때문에 그만큼 데이터베이스 성능을 향상시킬 수 있다는 장점을 가지고 있다.

동시성 제어 기술

동시성 제어 기법은 기존의 row locking 방식의 단점으로 지적돼 왔던 수정된 데이터(updating data)에 대한 읽기 연산이 대기(wait)하거나 이미 읽힌 데이터에 대해 수정연산이 장기간 대기하는 문제점을 해결하는 혁신적인 기술이다. 필자는 다중버전 기법(MVCC: Multi-Version Concurrency Control)을 이용한 동시성 제어 기법을 적용함으로써 위의 문제점을 해결했으며, 필요 없고 오래된 데이터를 즉시 회수함으로써 메모리의 낭비를 방지했다.
다중 버전 기법은 하나의 데이터에 대해 여러 개의 버전을 유지하여 읽기와 쓰기 연산에 대한 충돌을 없앰으로써, 최대의 성능을 발휘할 수 있도록 하는 것이다. 다중 버전 기법은 대량의 사용자가 접근하는 환경에서 최적의 성능을 발휘하고, 데이터베이스를 종료 하지 않고도 즉시 백업할 수 있는 핫 백업(hot-backup) 시스템의 가능성을 지원한다. 그러나 다중 버전 기법에서는 한 데이터에 대해 필요 없는 오래된 데이터가 생성될 수 있다. 따라서 garbage collection thread를 두어 이러한 데이터에 대해 필요 없게 된 시점에 즉각적으로 메모리 공간을 회수하여, 재사용할 수 있도록 조치함으로써 메모리 사용의 효율성을 극대화하는 기능이 반드시 수반되어야만 한다.

다중 사용자 처리 기술

데이터베이스에 대한 동시사용자 수는 데이터베이스의 특성 및 해당 시스템의 용량과 밀접한 관계를 가진다. 그러나 실제 시스템 용량이 늘어나는 만큼 데이터베이스가 지원하는 동시사용자 수가 정비례하지 않는 것이 일반적이다. 특히 데이터베이스가 지원하는 서비스 아키텍처가 이러한 시스템 자원에 관련된 문제와 직접적인 연관이 있다.
서비스 당 단일 프로세스를 생성하는 전통적인 구조에 의하면, 사용자 수만큼의 프로세스가 생성되어야 함을 의미한다. 따라서 이처럼 자원 낭비가 극심한 상태에서는 대용량 사용자 지원의 해결책을 찾기가 쉽지 않다. 만일 한정된 프로세스로 대량의 사용자를 지원한다고 하더라도 사용자 간에 시간을 두고 자원을 서로 나누어 쓰는 것이기 때문에 근본적인 해결책이 될 수는 없다.
이로 인해 현재 데이터베이스의 구조는 쓰레드 기반의 아키텍처로 옮겨가고 있는 추세다. 그러나 쓰레드 아키텍처 또한 구현 및 검증상의 어려움을 가지고 있으며 특히 다중 프로세스 환경보다 우수한 쓰레드 기반의 시스템 확장성(system scalability)과 서비스 확장성(load scalability)을 보장해야 하기 때문에 자칫 프로세스 구조의 데이터베이스 아키텍처보다 더 나쁜 수행 결과를 초래할 수 있다.
이러한 문제를 보완하기 위해서는 쓰레드 아키텍처를 기반으로 서비스 쓰레드 풀(pool) 및 서비스 세션 풀 두 단계의 구조적 기반을 제공하는 방법이 있다. 서비스 세션 풀은 클라이언트의 요청을 직접 담당하고 클라이언트에게 정보를 되돌려 주는 세션을 유지하는 것이며 서비스 쓰레드 풀은 이러한 클라이언트의 서비스를 실제로 하위 모듈에서 수행(execution)을 담당하는 것이다.
서비스 세션 풀과 서비스 쓰레드 풀의 개수는 프로퍼티를 통해 해당 시스템의 부하에 맞게 적절한 값으로 선택할 수 있게 함으로써 필요 이상의 서버자원을 소모하지 않도록 해야 한다. 또한 클라이언트에 대한 빠른 응답을 보장하기 위해 일정 개수까지의 클라이언트에게는 서비스 쓰레드와의 1:1 연결을 통해 최대의 성능을 보장하고, 일정 개수 이상의 클라이언트가 접속될 경우에는 N:N의 연결로 자동 변환하여 서버의 자원을 효율적으로 사용할 수 있는 클라이언트-서버간의 혼합 서비스(hybrid architecture) 방식이 요구된다.

인덱스 기술

디스크 기반의 전형적인 RDBMS들이 채택하고 있는 인덱스 기법은 B-tree 인덱스이다. 이 기법은 주로 디스크 I/O 횟수를 줄이는데 초점이 맞추어진 것으로서, 각 노드의 엔트리는 키 값과 데이터 페이지에 대한 포인터(RID)를 포함하고 있다. B-tree 인덱스는 데이터가 메모리에 상주한다는 생각보다는 디스크에 상주한다는 가정에 적합한 기법이다. 만일 원하는 데이터가 메모리(버퍼)에 존재한다면, 이 경우는 디스크 I/O 횟수를 줄이는 것보다는 CPU 사용 시간을 줄이는데 초점이 맞추어진 인덱스 기법을 사용해야 할 것이다.

<그림 5> B-tree 구조>
xEdit Image

B-tree를 이용하여 해당 레코드를 읽기 위해서는 먼저 이 레코드에 대한 엔트리를 포함하고 있는 노드를 찾고 이 노드에서 해당 엔트리를 찾은 다음, 엔트리에 있는 RID 값을 이용하여 데이터 페이지를 접근하고 이 데이터 페이지로부터 해당 레코드의 위치를 구한다.
일반적으로 메인 메모리 DBMS는 B-tree 인덱스 대신에 메인 메모리 접근에 효율적인 T-tree 인덱스 기법을 사용한다. T-tree는 엔트리 크기와 알고리즘이 B-tree 보다 경제적이다. B-tree의 엔트리가 해당 레코드를 포함하는 데이터 페이지를 가리키고 있는데 반해, T-tree의 각각의 엔트리는 해당 레코드의 메모리 주소를 직접 포인팅하고 있기 때문에 T-tree 인덱스는 논리적 주소를 물리적 주소로 변환하는 작업 없이 원하는 레코드를 빠르게 접근할 수 있다.
메인 메모리로 데이터를 관리하는데 있어서는 메모리 영역의 절약, 디스크 I/O의 제거, 간단한 알고리즘의 사용에 그 목적이 있다. T-tree는 인덱스 노드에 키 값을 포함하지 않고 직접 메모리 내의 레코드(data row)를 포인팅하기 때문에 메모리 사용량을 줄일 수 있다. 또한 인덱스 전체가 메인 메모리에 상주하므로 디스크 I/O를 하지 않는다. 그리고 알고리즘 자체가 매우 간단하여 코드의 복잡성과 코드 경로(code path)를 줄일 수 있다.

<그림 6> T-tree 구조
xEdit Image

> B-tree나 T-tree는 정확한 검색(exact match)보다는 범위 검색(range search)에 유용한 구조이다. 메인 메모리 DBMS는 정확한 값을 빠르게 찾기 위한 방법으로 해쉬 인덱스를 추가로 제공하기도 한다. 여기서 단순한 해쉬 인덱스를 사용하는 대신 성능과 인덱싱 용량을 증대하기 위하여 기본 해쉬 기법 대신 변형된 기법을 사용한다. 이를테면, ECBH(Extendible Chained Bucket Hash) 같은 것이다. ECBH는 체인 버켓 해슁 구조(CBH)와 확장 해슁 구조(EH)를 통합한 형태이다. ECBH는 ECBH는 EH의 단말 노드를 체인 버켓 해쉬 테이블과 포인터 체인으로 대체하여 CBH의 단점인 해쉬 테이블의 고정성을 EH로 보강한 구조이다. 이렇게 함으로써, ECBH는 해쉬 테이블의 확장성과 데이터의 저장성을 높였다.

<그림 7> ECBH 구조
xEdit Image

CPU 캐시를 고려한 기술

CPU가 데이터를 처리하기 위해서는 메모리로부터 연산자와 데이터를 읽어와야 한다. 일반적으로 CPU의 성능은 매우 빠르게 향상하고 있는 반면 메모리의 성능은 더디게 향상되고 있는 실정이다. 예를 들어 RISC 기반의 CPU는 1GHz인 반면 메모리의 접근 속도는 100MHz 정도이다.

<그림 8> CPU와 메모리의 성능 차이
xEdit Image

이 CPU의 경우 이론상으로 1초에 약 10억 개의 연산이 가능하지만, 메모리의 접근으로 인해 10배 정도 CPU 성능이 저하되는 현상이 발생한다. 이러한 문제점 해결을 위해 대부분 CPU는 캐시(cache) 기능을 포함하고 있는데, 이 캐시 조차도 성능을 고려해 L1 캐시, L2 캐시 등과 같이 여러 계층으로 설계하고 있다. 앞에서 예시한 CPU의 경우 L2 캐시를 도입하게 되면 캐시가 없는 경우보다 약 2배 정도의 성능 향상을 가져올 수 있다. 그만큼 메모리 접근 속도의 영향을 벗어나 CPU의 성능을 최대한으로 살릴 수 있게 되는 것이다.
결국 캐시 메모리를 채택한 CPU의 성능은 캐시 메모리의 크기와 캐시 계층을 얼마나 최적화 하느냐에 달려있는데, 이는 CPU 종류마다 다르게 채택되고 있다. 이미 언급했던 것처럼, 메모리 DB 최우선 목표는 성능이다. 따라서 성능 향상을 위한 모든 수단을 도입할 필요가 있으며, CPU 캐시를 고려한 프로그래밍도 고려 방법 중의 하나이다. 여기서는 캐시를 고려한 프로그램 작성 방법에 관하여 살펴 보도록 한다.

<그림 9> CPU Cache 구조
xEdit Image

한 연구 서적에서 발표된 바에 의하면, CPU의 사용 시간의 50% 이상이 메모리 접근에 따른 대기 시간임이 밝혀졌다(Where Does Time Go?, 1999, VLDB). 만일 캐시에 최적화된 프로그램을 작성할 수 있다면 20~30%의 성능을 향상시킬 수 있다. 그러나 각종 플랫폼별 고유의 캐시를 지원하고 있고 문맥교환(context switching)이 발생한 이후의 CPU 캐시는 이전의 캐시 패턴과는 무관할 가능성이 크기 때문에 오히려 성능을 저해하는 요인을 제공하는 결과를 초래할 수 있으므로, 캐시를 고려한 프로그래밍에는 세심한 주의가 요구된다.
캐시 프로그래밍이란 결국 캐시 미스(Cache Miss)를 줄이는 것이다. 이를 위해 먼저 캐시 시뮬레이터를 통해 통계적으로 대상 프로그램의 캐시 미스 영역을 찾은 후 병목 현상을 해결하는 것이다.
캐시 미스가 발생하는 경우와 해결 방법을 살펴보기로 한다. 최초 데이터 접근 시 반드시 발생하는 Compulsory Miss는 피하기가 어려우므로 해결 대상에서 제외한다. 또한 접근하려는 데이터가 캐시라인보다 클 경우에 발생하는 Capacity Miss는 데이터 구조의 압축으로 해결 가능하다. 마지막으로 접근하는 두 개의 데이터가 동시에 동일한 캐시라인으로 수렴되고, 준비된 Cache Way의 수가 부족할 때 발생하는 Conflict Miss는 어드레스를 서로 충돌하지 않게 변경함으로써 문제를 해결할 수 있다.

RDBMS 연동 기술

64비트 운영체제를 채택한 컴퓨터가 일반화되는 추세라 하더라도 하드웨어의 기술적인 문제 때문에 메인 메모리 크기의 한계가 존재한다. 현재 64비트 컴퓨터가 탑재하고 있는 메인 메모리의 최대 크기는 512GB가 한계다. 이 경우에 메인 메모리 DB의 최대 크기를 500 GB이상 구축하기는 힘들다. 따라서 이것보다 큰 대용량 데이터베이스의 관리는 힘들게 된다.
대용량 데이터베이스 서비스 환경에서 RDBMS 연동 에이전트의 역할은 활용도가 높은 데이터를 전용으로 처리하는 데이터베이스 캐싱 서버의 보완 역할을 담당하는 것이다. 이를 위하여 메인 메모리 DBMS는 기존의 디스크 기반 DBMS와 연동하기 위한 실시간 에이전트를 제공하여 대용량 DB는 디스크 기반 DBMS로 관리하고 그 중에서 가용성이 높은 일부 데이터(hot data)를 메인 메모리 DBMS가 관리하는 것이다.
일반적으로 이 에이전트는 사용자로부터 복제할 테이블의 정보를 구하여, 이 테이블들을 자동으로 메인 메모리 DB로 생성하는 캐싱(caching)과, 운영 중에 DB가 변경되면 실시간으로 변경된 내용을 RDBMS의 DB에 반영하는 리프레쉬(refresh)를 수행한다. 이렇게 함으로써 대용량 DB의 운용 성능을 향상시킬 수 있다. 연동 에이전트는 연결성(connectivity), 확장성(scalability), 고성능성을 제공해야 한다. 연결성은 타 시스템의 기존 DB와 별도의 프로그램 없이 최소한의 필요 정보만 입력함으로써 연결 가능할 뿐 아니라 필요한 정보를 바로 캐싱할 수 있어야 한다. 확장성은 외부 데이터 중에 성능 향상을 필요로 하는 데이터를 수시로 캐싱/리프레쉬 시키는 작업이 가능하도록 하고 제한된 메모리 내에서 필요한 데이터만 활용하도록 함으로써 확장성을 보장해야 한다. 고성능성은 연결성과 확장성을 이용하여 성능 향상을 요구하는 정보에 대한 작업이 필요 시점에 가능하도록 함으로써 최대의 성능을 발휘할 수 있도록 하는 것이다.

<그림 10> RDBMS 연동 에이전트의 데이터 흐름
xEdit Image

연동 에이전트는 원천 데이터베이스의 일부 테이블을 수직분할(vertical segmentation), 수평분할(horizontal segmentation), 수직-수평분할 할 수 있으며, 이 정보를 에이전트의 메타 데이터로 관리한다. 이 메타 데이터 정보는 캐싱 규칙(caching rule)에 의해 생성되는데 캐싱 규칙은 <연결 정보, 객체 정보, 매핑 정보>로 구성된다. 연결정보는 원천 DB의 사용자 비밀 번호, 객체정보는 캐싱할 테이블에 관한 정보, 그리고 매핑 정보는 캐싱할 테이블들의 분할 정보를 각각 나타낸다.
메타 데이터 정보를 이용하여 실시간 에이전트는 메인 메모리 DB에 새로운 테이블을 생성하고 원천 DB로부터 지정된 데이터 만을 메인 메모리 DB로 캐싱한다. 캐싱된 테이블에 변경이 발생하면, 메인 메모리 DBMS는 이 변경 정보를 취합하여 실시간으로 RDBMS DB에 반영한다.
지금까지 메인 메모리 DBMS에 적용된 기술들을 살펴보았다. 물론 위의 기술들이 전부 다는 아니고 기존의 디스크 기반 DBMS와 차별되는 기술들을 위주로 살펴본 것이다. 또한 모든 메인 메모리 DBMS가 위의 기술들을 적용한 것도 아닐 것으로 여긴다. 각 제품마다 동일 기능에 대해서 나름대로의 특화된 기술들을 적용하였을 것이다. 다만 그 기술들이 메인 메모리 DBMS의 주 목적 중 하나인 성능 향상에 기반을 두고 있음은 분명하다.
데이터베이스의 안정성과 신뢰성을 제공하기 위해 DBMS 기술 중에서 매우 중요한 로깅(logging) 및 회복(recovery)에 관한 내용은 다음 호에서 살펴 보기로 한다.

[Top]
No.
제목
작성자
작성일
조회
234회 메인 메모리 DBMS 현황 및 전망
최한열
2005-04-21
13732
223회: 메인 메모리 DBMS의 안정성과 이중화
최한열
2005-04-21
18443
212회 메인 메모리 DBMS 기술
최한열
2005-04-21
14622
201회: 메인 메모리 DBMS의 등장 배경과 개요
최한열
2005-04-21
14004
Valid XHTML 1.0!
All about the DATABASE... Copyleft 1999-2022 DSN, All rights reserved.
작업시간: 0.025초, 이곳 서비스는
	PostgreSQL v14.2로 자료를 관리합니다