main-memory database systems –...

Main-Memory Database Systems – Overview

2006년 1학기

실시간 데이터베이스

김 영 국

충남대학교 전기정보통신공학부

실시간 데이터베이스 Main-Memory Database Systems - Overview 2

OutlineMM-DBMS 등장배경 및 개요

MM-DBMS 요소기술

접근 기법(인덱싱)동시성 제어

회복 관리 기법

국내외 MM-DBMS 개발 현황

MM-DBMS 활용사례

결론 및 향후 전망


MM-DBMS의 등장배경

실시간 데이터 처리 요구 증가

웹 기반 IT 환경의 보편화

오픈 액세스 허용으로 예측 불가능한 시스템 접근 부하

실시간 성능을 요하는 내장형 시스템 응용의 증가

기존 DBMS 한계 봉착

기존의 디스크기반 범용 DBMS가 성능요구조건을 만족시키지

못하는 응용의 증가

MM-DBMS 구현의 현실화

메모리 집적도의 향상 및 가격하락

64비트 컴퓨팅 등


TerminologyMM-DBMS (Main-Memory DBMS)

주기억장치 상주형 데이터베이스관리시스템

DR-DBMS (Disk Resident DBMS)디스크 기반 데이터베이스관리시스템


MM-DBMS vs. DR-DBMS저장매체에 대한 측면

MM-DBMS : 데이터베이스를 주기억장치에 저장

DR-DBMS : 데이터베이스를 디스크에 저장, 필요에 따라

주기억장치에 저장, 사용

목적에 대한 측면

MM-DBMS : 데이터의 처리속도 향상

DR-DBMS : 데이터베이스 시스템의 안정적 운영 및 데이터의

효율적인 운영에 중점

시스템 설계 고려 사항

MM-DBMS : CPU 처리 시간 최소화, 메모리 공간 사용 최소화

DR-DBMS : DISK 접근 횟수 최소화, 데이터 clustering 향상


주기억장치의 특성

빠른 접근속도

잠금에 의한 블록킹 시간 감소

휘발성 메모리

백업 및 파손 회복 기능이 중요

접근 비용 예측 가능

접근 비용이 데이터 크기에 비례

데이터 배치 상태는 액세스 속도와 무관

클러스터링 불필요


Typical Structure of MM-DBMS

Logging + Fuzzy Checkpoint

nonvolatileLog Buffer

Memory

Archive Database

Log Disk

Main Memory Database

DBMS

Optional

nonvolatile Database

Main Memory Optional


MM-DBMS의 요소기술

질의처리 기법

데이터 접근 및 저장 기법(인덱싱)동시성 제어기법

회복기법

이중화 기법

DR-DBMS와의 연동기법


데이터 접근 및 저장 기법 (인덱싱)DR-DBMS와 MM-DBMS의 인덱싱 기법 비교

트리 계열 인덱스

T-트리

해시 계열 인덱스

ECBH


인덱싱 기법 비교

DR-DBMS디스크의 I/O 최소화

클러스터링

B-트리

인덱스 노드는 키 값과 데이터에 대한 포인터 필요

MM-DBMS메모리 공간의 효율적인 사용

접근 비용이 저렴한 인덱스 요구

ECBH, T-트리

인덱스 노드는 포인터만 필요


트리 계열 인덱스

키가 일정한 순서로 유지

일정한 범위가 주어지는 연산 시 유리

T-트리

접근속도와 메모리 사용측면에서 효율적


T-트리

한 노드에 많은 원소를 갖는 이진 트리

AVL 트리와 B-트리의 조합

키를 포함하는 레코드의 메모리 주소를 데이터로 사용

키 값을 구하는 연산으로 인한 부하가 전체 인덱스의 처리 속도에

거의 영향을 미치지 않음

T-트리의 노드 내에 데이터는 항상 크기 순으로 유지

T-트리의 노드

내부 노드

– 오른쪽, 왼쪽 서브 트리를 가짐

– 내부 노드에 포함될 수 있는 데이터의 개수는 T-트리 생성할 때 결정

반쪽 리프 노드

– 방향과 상관없이 한쪽 서브 트리만 가짐

리프 노드


T-트리의 구조

control

control

control control control control

control

controlData


T-트리의 연산

탐색 (이진트리와 같음)루트로부터 탐색

찾는 값이 노드의 최소값 보다 작으면 왼쪽 크면 오른쪽

그 외 노드에 포함된 데이터들과 비교 탐색

삽입

삽입한 노드 탐색 -> A노드 A에 공간이 있으면 삽입

없으면 최소 데이터를 삭제, 그 공간에 데이터 삽입

삭제한 데이터를 A노드 왼쪽 서브 트리에서 가장 큰 데이터를 가진

노드로 이동해서 위의 2번째 과정 반복

리프 노드까지 삽입할 위치가 없으면 리프노드의 왼쪽 노드를 새로

생성하고 삽입

노드의 균형인자가 2이상이면 회전 규칙 적용


T-트리의 연산 (Cont.)삭제

삭제할 데이터 검색 -> 노드 A탐색의 데이터

A가 내부 노드이고 데이터의 개수가 MinT보다 크면 삭제

MinT보다 작으면, A의 데이터를 삭제 후 노드 A의 왼쪽 서브트리

에서 가장 큰 값을 삭제(아래 진행 과정) 후 이를 현재 노드 A에 삽입

노드 A가 반쪽 리프 노드에서 데이터 삭제

– 데이터가 남아있지 않으면 자식 노드와 병합하고 노드의 균형인자를 조정

노드 A가 리프 노드에서 데이터 삭제

– 데이터가 남아 있지 않으면 노드를 삭제하고 노드의 균형인자를 조정


T-트리의 회전규칙

특수 경우

적용될 회전 규칙이 RL 또는 LR노드 A와 노드 B가 반쪽 리프 노드

노드 C는 리프 노드이고 포함되는 데이터와 오직 한 개인 경우

노드 B의 데이터를 노드 C가 꽉 차도록 이동 후 회전 규칙을 적용

control

control

control

control

control

control

A

B

C

A

B

C

control

control control

C

ABLR


T-트리의 회전규칙 (Cont.)그 외의 경우는 AVL트리의 회전 규칙과 동일

AVL트리의 회전규칙

ABh

h h+1

AB

h h

h+1

AB h

hh+1

AB

hh

h+1

RR LL

AB

Chh

h|1

h

A B

C

h hh|1

h

A

B

Ch

h

h|1

h

B A

C

h hh|1

h

RL LR


해싱 계열 인덱스

키의 순서에 관계없어 무작위로 유지

특정한 키에 의한 빠른 접근

ECBH(CH와 CBH을 결합)


EH (Extended Hashing)구성

리프 페이지 : 해시된 데이터 유지

디렉토리 : 리프 페이지에 대한 식별자 유지

단점리프 노드의 크기가 상대적으로 작을 경우 디렉토리의 크기가커짐

페이지 분리리프 페이지에 들어갈 공간이 없으면 d’를 1 증가

디렉토리 분리 : 리프 페이지가 디렉토리에 유지될 수 있는개수보다 많아지는 경우 d가 1증가

– 전역 깊이 d : 디렉토리에 유지되는 깊이 정보

– 지역 깊이 d’ : 리프 페이지에 유지되는 깊이 정보( d’ ≤ d )


EH (Cont.)구조

3000001010011100101110111

2

3

3

1


CBH (Chain Bucket Hashing)동일한 해시 값들을 연결 리스트에 유지

해시 테이블 크기가 결정되어 있는 정적 구조

구성해싱 테이블

같은 해시 어드레스를 가진 RID의 링크드 리스트

장점정적 파일에 대한 가장 빠른 접근 시간

단점삽입된 데이터가 많을 때 긴 체인이 생성됨

데이터 크기가 작을 때 주소 저장을 위한 공간이 데이터 저장 공간보다 많이 소모

동적 파일에서 확장/축소 시 해시 테이블 전체를 재구성


CBH (cont.)구조

e.g., 해시 함수 : 8로 나눈 나머지

0123456

Hash Table

7

16 24110

4 12 20 285 21

7


ECBH (Extended Chained Bucket Hashing)

EH와 CBH를 결합해서 만든 해싱 기법

EH에서의 단계적인 확장의 용이성을 취함

CBH에서의 높은 수행능력

구성

EH 테이블 : CBH 테이블에 대한 주소를 유지

CBH 테이블 : RID 풀에 저장된, CBH 테이블의 각 엔트리와

관련된 RID리스트에 대한 주소 유지

RID(슬롯 식별자) 풀


ECBH (Cont.)구조

3000001010011100101110111

2

3

3

1

R(000)

R(001) R(010)

R(011) R(100)

R(111)

R(101) R(110)

RID pool


MM-DBMS를 위한 인덱싱 기법 - 요약

요구사항접근 비용이 저렴

메모리 효율성 증대

T-트리빠른 검색

메모리 활용의 최대화

ECBH단계적인 확장 - 메모리 효율성 증대

CBH의 빠른 수행 능력


MM-DBMS 동시성 제어 기법

잠금 기반 동시성 제어 기법

구현이 용이

응용에 따른 잠금 단위, 잠금 정보 유지 방법의 최적화

대부분의 시스템이 사용

2PL

낙관적 동시성 제어 기법

충돌이 적은 경우 효율적

구현이 어려움

거의 사용 안 함


잠금 기반 동시성 제어

DRDB vs. MMDB

<DRDB> <MMDB>

속도: 느리다 빠르다

lock holding time: 길다 짧다

lock contention: 중요 덜 중요

잠금 단위: 작게(field, record) 크게(relation, DB)


잠금 기반 동시성 제어 (cont.)

잠금의 단위가 커지면충돌 발생 가능성 증가

충돌 해소 빠름

잠금 단위가 전체 DB이면트랜잭션을 순차적으로 수행

잠금의 설정/해제, deadlock의 검출/처리 오버헤드 제거

CPU 캐쉬 메모리의 flush 횟수가 현저히 줄어듬

긴 트랜잭션이 존재할 경우 부적절 (fairness 정책 위배)

응용프로그램의 성격에 따라 적절한 잠금 단위 설정



구현방법 (잠금 테이블의 구조)해쉬 테이블 이용

– 디스크 기반 DBMS

– 모든 객체에 대한 잠금 정보를 주기억 장치 내 해쉬 테이블에 둠

– 객체 자체에는 잠금 정보가 없음

객체 자신이 잠금 정보 소유

– 주기억장치 상주형 DBMS

– 각각의 객체에 몇 bit를 할당하여 잠금 설정 상태 표시

(예: 1’st bit: 잠금 상태, 2’nd bit:기다리는 트랜잭션 존재 유무,

해쉬테이블: 기다리는 트랜잭션 id)

– 잠금의 설정 및 해제를 적은 수의 기계어로 수행

– 잠금 설정/해제 시 해쉬 테이블을 찾는 오버헤드 없음



Example

System Name Concurrency

MM-DBMS 2-phase locking of relations

MARS 2-phase locking of relations

TPK serial transaction execution

System M 2-phase locking, minimize concurrency

Fast Path record-granule locking

Dali item(record) level locking


낙관적 동시성 제어

방법

각 트랜잭션이 수행된 후, 데이타의 충돌이 있는지 여부를

판단하고 충돌이 있는 경우 그 트랜잭션을 철회

특징

conflict resolution

read phase, validation phase, write phase


MM-DBMS 동시성 제어 기법 - 요약

응용 분야에 따른 적절한 잠금 단위 설정 필요

잠금 정보의 객체 자체 보관

잠금 설정/해제 비용 적음

구현 용이

===> 잠금 기반 동시성 제어가 더 효과적일 수 있음


회복(Recovery) 관리기법

MM-DBMS 회복 관리 기법 개요

MM-DBMS 회복 관리 기법의 구성 요소


MM-DBMS 회복 기법 개요

회복(Recovery)시스템 및 media failure 발생 이후 일관된 데이타베이스 상태로

복구시켜 주는 것

DR-DBMS 회복 vs. MM-DBMS 회복

DR-DBMS에서의 회복

– DB의 원본이 디스크와 같은 비휘발성 저장장치에 상주

– 시스템 붕괴 시에도 주기억 장치 버퍼내의 데이터만이 손상, 디스크에 있는 전체 DB에는 영향을 주지 않음

MM-DBMS에서의 회복

– DB의 원본이 휘발성 주기억장치에 상주

– 시스템 붕괴 시 DB 전체가 손실 → 회복 기법의 중요성 대두


MM-DBMS 회복 기법 개요 (cont.)MM-DBMS 회복 기법 요구 사항

회복 관련 작업으로 인해 MM-DBMS의 성능 저하 가능성

안정적이면서도 오버헤드가 적은 회복 기법 필요

회복을 위해 필요한 부가적인 작업들

로깅, 체크포인팅, Restart

MM-DBMS에서의 유일한 I/O 유발 요소

회복 I/O로 인해 트랜잭션 처리 속도에 영향을 미치면 안됨


MM-DBMS의 일반적인 시스템 모델

CPU DBMS

Archive DB

LogLog Buffer

MMDB

Main Memory


회복 기법에 영향을 주는 요소

안전 기억 장치의 사용 여부

데이터 갱신 방식


안전 기억 장치

전원이 차단되더라도 그 내용을 보관할 수 있는 비휘발성 기억장치

로그 저장이나 shadow 메모리 등에 사용

Battery-backup RAM, ...장점

트랜잭션 응답 시간 단축

단점

가격이 비싸고 접근 속도 떨어짐

일반 RAM보다 2~4배 느림


데이터 갱신 방식

직접 갱신(in-place update)데이터 변경 시 기존 데이터 위에 새로운 내용 overwrite

Undo를 위해 기존 데이터를 로그에 기록

장점 : 처리 속도가 빠름

단점 : redo/undo를 위한 로그가 필요하므로 로그의 양이 많고

회복과정이 복잡

shadow 갱신

데이터 변경 시 shadow 메모리를 변경하고 트랜잭션 commit 시점에

shadow 메모리의 내용을 DB로 반영

장점 : undo가 필요 없고 redo 로그만 기록하므로 로그의 양이 작고

회복이 간단

단점 : 갱신 데이터에 대한 두 번의 복사 과정으로 시간이 많이 걸리고

메모리 많이 사용


MM-DBMS 회복 기법의 구성 요소

로깅 및 트랜잭션 commit 체크포인트(Checkpoint) Restart


로깅 및 트랜잭션 Commit로깅 규칙(Logging Rules)

WAL(Write Ahead Logging)– 로그 정보는 데이타베이스에 변경사항이 반영되기 전에 비휘발성 메모리에

먼저 기록되어야 함

Commit Rule– 트랜잭션이 commit되면 그 효과는 failure와 관계없이 데이타베이스에 영구히

반영되어야만 함

LAW(Logging After Writing)– 변경된 데이터의 사후 이미지(after image)가 변경사항이 데이타베이스에

반영된 후에 로그에 기록 되어져야 함

MM-DBMS에서의 로깅의 특징

commit된 트랜잭션의 로그 정보는 회복 시 사용하기 위해 로그 버퍼에서

비휘발성의 안전한 저장 장치로 이동되어야 함


로깅 및 트랜잭션 Commit (cont.)안전 로그 저장 장치의 종류

디스크

– 장점 : 별도의 하드웨어 비용 불필요

– 단점 : – 디스크 입출력 처리에 의한 오버헤드로 인해 트랜잭션commit 시간이 오래 걸림

– lock holding time이 증가

– 트랜잭션 처리가 지연됨으로써 처리량이 감소

안전 기억 장치(stable memory)– 장점 : 입출력 처리에 따른 오버헤드는 발생하지 않음

– 단점 : 별도의 하드웨어 비용 문제 발생


로깅 및 트랜잭션 Commit (cont.)Commit 방식

Immediate Commit– commit시 로그 버퍼 내의 해당 트랜잭션의 모든 로그 레코드를 안전

로그 저장장치로 이동

– 디스크 I/O가 빈번히 발생 -> 성능 저하

Group Commit– 로그 버퍼가 가득 차는 경우에만 안전 로그 저장 장치로 이동

– I/O 횟수 감소, 각 트랜잭션의 commit시점이 늦어짐 -> 동시성 저하

Precommit– commit시 로그 버퍼에만 기록하고 주기억장치의 데이터를 unlock– 트랜잭션 처리량 증대

– strict 2PL을 사용하고 로그버퍼에 로그가 순차적으로 기록되므로commit 순서가 보장됨으로써 일관성 유지


체크포인트

데이타베이스의 변경 부분을 Archive DB에 반영

가능한 최근의 데이터를 Archive DB에 기록해둠으로써회복 과정의 부담을 줄이기 위함


체크포인트 (cont.)일관성 유지 방법에 따른 분류

동기 방식

– 트랜잭션이나 action 수행과 동기를 맞추는 방식으로 체크포인팅을

할 때 트랜잭션의 수행을 정지시키므로 성능 저하

– 논리적 로그 기록 방식을 적용함으로써 로그를 간단히 기록 가능

– transaction consistency 체크포인팅(TCC), action consistency 체크포인팅(ACC)

비동기 방식

– 트랜잭션의 수행에 영향을 주지 않고 체크포인팅을 수행함으로써

성능에 영향을 미치지 않음

– 물리적 로그 기록 방식만 지원되므로 로그의 양이 많아짐

– fuzzy 체크포인팅


체크포인트 (cont.)체크포인팅 전략에 따른 분류

fuzzy 체크포인팅

– 체크포인팅에 의해 디스크로 기록된 image에 체크포인팅 중에

발생한 로그를 적용하면 ACC 나 TCC 방식과 같은 image를 얻을 수

있다

– 장점 : 트랜잭션 처리량이 가장 높음

– 단점 : commit되지 않은 트랜잭션이 디스크에 반영될 수 있음

Black & White– data update시 set(white), disk 반영시 reset(black)– 구현 간단(장점), 트랜잭션의 abort/restart가 자주 발생(단점)

Copy-on-Update– 데이터 복사 후 수정, commit시에 DB에 반영

– 구현 복잡


RestartRestart

시스템 붕괴 후 데이타베이스를 가장 최근의 일관된 상태로 복구

Restart 전략

Database Prefetching– 전체 DB를 주기억장치에 적재 후 트랜잭션 처리 시작

– 장점 : 구현이 쉽고 트랜잭션 처리 시 page fault가 적게 발생함으로써 성능

향상

– 단점 : 시스템 재 가동 후 DB 적재 시간이 많이 걸림으로써 트랜잭션 전체처리량 감소

Page Prefetching– 트랜잭션을 분석하여 먼저 필요로 하는 페이지를 적재

– 장점 : 붕괴 후 시스템 설정 시간이 Database Prefetching 보다 단축됨으로써트랜잭션 처리량 많아짐

– 단점 : 필요한 페이지를 파악하고 우선 순위에 따라 트랜잭션 처리를 하면서적재해야 하므로 구현이 어려움


Restart (cont.)Demand Loading

– 로그 내용을 주기억장치로 적재한 후에 트랜잭션 처리를 시작

– 트랜잭션이 주기억장치의 데이타베이스에 필요한 내용이 없으면

디스크로부터 필요한 데이타베이스를 적재하고 로그의 내용을

적재된 데이타베이스에 반영

– 장점 : 회복 후 트랜잭션 처리를 즉시 시작할 수 있어 처리 속도 향상

– 단점 : 트랜잭션이 필요한 데이터베이스를 디스크로부터 적재 시

데이터 적재량이 매우 높아 트랜잭션의 대기 시간이 길어짐

Demand Paging– Demand Loading과 유사하나 페이지 단위로 데이타베이스를 적재

– 장점 : 페이지 단위로 디스크를 접근하므로 트랜잭션 처리 시간 향상

– 단점 : 전체 데이타베이스가 적재되기 까지 Page fault가 많이

발생함으로서 처리량 저하


MM-DBMS 회복 관리 기법 - 요약

MM-DBMS의 주요 목표인 높은 처리 성능을 저하시키지 않는

범위에서 로깅, 체크포인팅 등 회복 관리에 관련된 작업들이

수행되어야 함

MM-DBMS의 대형화 추세에 따라 전체 데이타베이스가 MM-DBMS에

존재하지 않을 경우도 고려해야 함

MM-DBMS의 시스템 붕괴 후 Restart 시 트랜잭션 처리가 중단되는

시스템 down-time을 줄이기 위한 incremental restart 기법 및

파티션 등과 같은 독립적인 단위로 회복 처리를 하는 것이 바람직함

메모리 기술 발달 및 가격의 저렴화에 따라 MM-DBMS의 회복 관련

오버헤드를 줄이기 위해 stable memory를 사용하여 효율적인 회복

관리를 할 수 있는 기법이 필요


국내외 MM-DBMS 개발 현황

국외 MM-DBMS 개발 현황System-M, MARS, Dali (Bell Lab.)ClustRa, Angara, DataBlitz (Lucent)TimesTen (Oracle)

국내 MM-DBMS 개발 현황Mr.RT, DREAMS, Tachyon (ETRI)Altibase ((주)알티베이스)Kairos ((주)리얼타임테크) P*Time, RtPlus, Telcobase, Zerowait, etc.


Typical Target Application디스크 기반의 상용 DBMS가 목표 응용시스템의 성능요구조건을 만족시키지 못하는 경우

해결책

자주 액세스되고, 갱신이 빈번하지 않은 정보 (Hot-Spot data)를MM-DBMS에 저장, 일차 단순검색 지원

상세정보에 대한 검색요구는 디스크기반 DBMS에서 처리

User

Retrieval System/ DBMS

1.Query(ask core-information)

2.core-information

3.ask detail-information

4.detail-information

Core(Hot spot)-Information

Retrieval System

Core(Hot spot)-Information

Retrieval System

developmentcurrent

User

Retrieval System / DBMS

1.Query

2.core-information

3.ask detail-information

4.detail-information


• 디스크 병목 현상 제거

• 균등한 검색속도 보장

• R-DB User 수 추가 부담 해소

• 디스크 병목 현상 제거

• 균등한 검색속도 보장

• R-DB User 수 추가 부담 해소

검색클라이언트

마스터정보

색인정보

간략정보

RT-MM-DB(in Kairos)

Disk-based R-DB (in Oracle)

검색 엔진검색 엔진

1) 질의

4) 간략정보 리스트

5) 서지제어번호

7) 마스터 정보

2) 검색된 문헌의서지제어번호

3) 간략정보

6) 마스터정보

활용사례 - 서지정보 검색시스템


기타 MM-DBMS 활용사례

인터넷 가입자 인증

실시간 주식 시세 분석

차세대 빌링 시스템

휴대 인터넷


결론 및 향후전망 (1)MM-DBMS의 필요성 증대

웹 기반 IT 환경의 보편화 -> 오픈 액세스 허용에 따른 부하 증가

실시간 내장형 시스템 응용의 증가

기존의 디스크기반 범용 DBMS가 성능요구조건을 만족시키지 못하는응용의 증가

메모리 집적도의 향상 및 가격하락, 64비트 컴퓨팅 등 주기억장치상주형 DBMS 구현의 현실화

몇몇 외국업체가 독점하고 있는 범용 디스크기반의 DBMS 시장과는 달리 MM-DBMS 시장은 국내 개발제품이 가격경쟁력뿐만 아니라 기술 경쟁력 및 현실성을 가질 수 있음

실시간 응용분야의 성격이 다양하여 한 제품이 모든 응용분야에최적일 수 없음

특정 응용분야에 쉽게 커스터마이즈 될 수 있는 융통성 있는 구조를갖는 MM-DBMS 필요


결론 및 향후전망 (2)향후 MM-DBMS 연구 개발 방향

Flexibility & Adaptability: 융통성 있는 시스템 구조 제공

– 객체지향, 모듈화

Multiple Functionality: 다양하고 선택 가능한 기능 제공

– 복수의 트랜잭션 스케쥴링, 동시성 제어, 회복기법 등

Timeliness: 실시간 성능 지원

Portability: 다양한 운영 환경지원

– CPU’s, 범용 OS’s, RTOS’s

Scalability & Extensibility: 확장 가능성

– 분산(Distributed), 내장(Embedded), 이동(Mobile)형

main-memory database systems –...

Documents