Hybrid MM DBMS ‘ALTIBASE 4’ Technical Features : Part I ... · MVCC에서 Record 버전 간의 시간순서를 결정하기 위한 방식 각 Record의 생성 시점(commit Time)을

Hybrid MM DBMS Hybrid MM DBMS ‘‘ALTIBASE 4ALTIBASE 4’’Technical Features : Part ITechnical Features : Part I

Storage ManagerStorage Manager

(주)알티베이스 김성진[email protected]

- 2 -

1. Problems & Goals2. SM Architecture3. Concurrency Control4. TableSpace5. Layers6. Conclusions

CONTENTS

- 3 -

Problems & Goals

- 4 -

Problems & Goals

“혁명적인 DBMS의 개발”누구도 가보지 않은 미지의 대륙 => What’s it?

Goal : Hybrid MM DBMS = MMDB + DRDB

- Hybrid Car 다양한 상황에서 최적의 구동 방법 선택

메모리

상주

테이블

응용응용 응용응용응용응용

디스크

상주

테이블

ALTIBASE 4

- 5 -

Problems & Goals

Storage Manager 입장에서의 도전 과제

성능

- MMDB : 기존의 성능을 저해하지 않아야 함

- DRDB : 현존하는 상용 DRDBMS 능가

기능

- MMDB : ALTIBASE 3의 지원 기능 모두 수용

- DRDB : 대용량 Disk 기반 테이블 제공

안정성

- 상용 DRDBMS에 필적할 만큼의 품질 요구

- 고객의 비명 : “으악..또 죽었어...”

- 6 -

Problems & Goals

Problems

개발자 신념의 문제- “과연 이게 가능한 목표인가?”- “시장에서 성공할 만한 제품인가?”

기술적 문제- 어떤 Architecture로 설계를 해야 하나?

- 어떤 방식의 동시성 제어를 사용해야 하나?

- 적절한 복구 기법이 존재는 하는 건지?

- “Replication도 되어야 해!(상위 관리자)”- “새로운 백업 정책도 세워야 하는데…(혼잣말)”- “절대 서버가 죽어서는 안된다(CEO)”- ……… T T;;

- 7 -

Architecture

- 8 -

Storage Manager Architecture

기존 Architecture

C++ class 단위의 모듈 구성

Object Oriented 설계 기법에 맞는 구조

문제점

Interface

Transaction

Lock

Page

Recovery

Record

TableIndex

System Software에이러한 형태가 바람직한가?

- 9 -


Layered Architecture

A hierarchy of Layers

Layer : 동일 혹은 유사한 기능적 집합

단위

간결, 직관적

한 Layer는 바로 하위의 Layer를 호출,

그 반대는 허용하지 않음

Depth의 숫자에 따른 성능 Tradeoff

예) 1968, THETHE O/S by Dijkstra

Structure of the THE Operating System

- 10 -


완화된 Layered Architecture

목적 : Performance 향상

Depth에 따른 Overhead 단점 극복

상위 Layer는 임의의 하위 Layer 호출

하위 Layer는 transparent callback을 통해 상위 Layer를

호출

Advantages

Layer 및 모듈의 독립성 보장 : Complexity ↓↓Unit Test가 용이

- 하위 상위로의 단계적 통합 테스트 가능

- Unit Test SM Regression Test Server

Regression Test

- 11 -


Layered Architecture of ALTIBASE 4/SM (8 Layer)

Index Layer(n)Record Layer(c)Page Layer(p)

Recovery Layer(r)

Transaction Layer(x,l)Application Layer(a)

Interface Layer(i)

Resource Layer(m)

상위 QP 모듈에의해호출

SM 응용 Thread (GC, Refine)

Transaction과 Lock Manager

각종커서및인덱스

Logical 정보를담고있는 Record 구조

Physical Page Structure, Extent,Segment

Logging , Restart Recovery 관련

Memory/Buffer Mgr/Disk Mgr

- 12 -

Concurrency Control

- 13 -

Concurrency Control : Introduction

What is Concurrency Control?How to guarantee the consistency of data ?

What Happen?

GAMESTAR 34

ModifyRead

Transaction 1 Transaction 2

- 14 -

Concurrency Control : SVCC

SVCC(Single Version Concurrency Control)

Ex) IBM DB2, MS SQL, Sybase, 바다, Unisql(2PL)

해당 Record에 lock을 획득

Lock escalation 발생 (Lock 정보가 별도의 Hash에 존재)

Read/Modify 연산간의 Conflict 발생 low performance

Exclusive Mode

GAMESTAR 34

Read Modify


- 15 -

Concurrency Control : SVCC


최악의 상황

Exclusive Mode

GAMESTAR 34

Read Modify

TX1

TX2

TX3TX4 TX5 TX6

Transaction X

- 16 -

Concurrency Control : MVCC

MVCC(Multi Version Concurrency Control)

Ex) ALTIBASE, Oracle, PostgreSQL, Innodb

No Read Lock, Modify Record X Lock

Lock escalation 필요 없음 (Record 내에 Lock 정보 존재)

Read/Modify 연산간의 Conflict 없음 높은 성능

Exclusive ModeFOREVER 34GAMESTAR 34

Read Modify


- 17 -

Concurrency Control : MVCC Issues

MVCC Issues

Where is the Old View (Record)?

SCN & Transaction View vs Statement View 선택

Who can do the Garbage Collection ?

Index 처리

Issue 해결 방법에 따른 해당 DBMS의 기능 및 성능상의 현격한

차이 발생

Toy or Pre-mature Product vs Commercial Product

- 18 -

Concurrency Control : Old View

Where is the Old View?

out-place (fast for getting old view)

- ALTIBASE 3, PostgreSQL, ALTIBASE 4 Memory Table

In-place (slow, but size efficient)

- Oracle, innodb, ALTIBASE 4 Disk Table

FOREVER GAMESTARGAMESTAROld New

FOREVER OldNew

Data PageData Page

Out-place (RID 변경)

Data PageData Page Undo AreaUndo Area

In-Place(RID 유지)

- 19 -

Concurrency Control : SCN

SCN(System Commit Number) 이란?MVCC에서 Record 버전 간의 시간순서를 결정하기 위한 방식

각 Record의 생성 시점(commit Time)을 SCN으로 표현

Cursor는 자신의 고유한 SCN을 기반으로 Record 선택

Transaction View vs Statement View 선택Statement 단위의 View가 일반적

- Oracle, ALTIBASE, Mysql(slow)

A100

B110

C120

delete140

A BUpdate

B CUpdate

CDelete

A105

B115

C120

No Record

160

Statementview

Transactionview

A105

Tx begin

A105

A105

A105

AInsert

- 20 -

Concurrency Control : GC

Garbage Collection

Update/Delete에 의해 생긴 Old View공간을 회수하는 작업

현재 Open된 Statement의 SCN의 최소값 보다 더 작은

commit SCN이 존재할 경우, 공간 회수 가능.

방식

- 별도의 Context 이용 (ALTIBASE 4)

• 순차적인 공간 회수 가능

• 완전한 데이터 공간 회수 가능(No Lost)

• On-Line 트랜잭션의 성능에 영향이 없음

- On-Line 트랜잭션 이용(Oracle)

• 임의의 공간 회수.(select 연산에 의함)

• 일정시간이 지나도 완전한 회수는 쉽지 않음.

• 해당 트랜잭션의 성능에 영향을 미침

- 21 -

Concurrency Control : Index

Index 처리

정형화하기 힘든 까다로운 문제들이 다수 출현

MVCC하에서 Record 변경시 관련 Index 만을 변경?

Unique Index에 대한 Update 처리(update J=J+1)

Primary Index vs Secondary Index

Index 동시성 제어 기법 : Tree Latch vs Node Latch

Concurrent 변경에 따른 recovery problem

- 22 -

Concurrency Control : 정리

Concurrency Control의 선택


- 전통적인 Lock 기법

- 서로 다른 종류의 Tx 발생시 성능 저하 가능성

MVCC (Multi Version Concurrency Control)

- 연산간의 충돌 최소화 높은 성능

ALTIBASE

- MVCC 기법 중 각 부분의 장점을 채택

• Memory Out-Place, Disk In-Place

• 최적의 Garbage Collection 방식

• 빠른 Statement View 제공

• 고기능 Index 처리 기법 구현

- 23 -

TableSpace

- 24 -

TableSpace : 개념

TableSpace : an allocation of space in the database that can contain persistent schema objects.

현존하는 대부분의 DRDBMS에서 지원

ALTIBASE 4부터 지원

기존 응용 프로그램의 호환성

DRDBMS 사용자의 쉬운 접근성

Schema 설계 및 유지 보수의 편의성

- 25 -

TableSpace : 문제 및 해결

Problems.ALTIBASE 4 MMDBMS에서 어떠한 UI 형태?

Memory Table은 어떤 영역에 포함되어야 하나?

해결 : “Memory 공간도 하나의 TableSpace!!”일관성 있는 DBMS 접근방법 제공

ALTIBASE 4에서 지원하는 TableSpace 종류

1. Memory TableSpace

2. System Data TableSpace

3. System Undo TableSpace

4. System Temp TableSpace

5. User Defined Data TableSpace

6. User Defined Temp TableSpace

- 26 -

TableSpace : example

Use Case

Create Tablespace Create Tablespace mySpacemySpace Extent SIZE 320KExtent SIZE 320KDATAFILE DATAFILE ‘‘/alti/dbs/data1.tbs/alti/dbs/data1.tbs’’ SIZE 100M SIZE 100M

AUTOEXTEND ON NEXT 10K MAXSIZE 1000M;AUTOEXTEND ON NEXT 10K MAXSIZE 1000M;

Create table game (name char(32)) [tablespace sys_tbs_memory];Create table game (name char(32)) [tablespace sys_tbs_memory];Insert into game values(Insert into game values(‘‘gamestargamestar’’););

Create table star (id integer, title char(32)) tablespace mySpacCreate table star (id integer, title char(32)) tablespace mySpace;e;Create Index starIdx on game (id) tablespace mySpace;Create Index starIdx on game (id) tablespace mySpace;Insert into star values(1, Insert into star values(1, ‘‘gamestargamestar’’););

<Memory + Disk Hybrid Join Query ><Memory + Disk Hybrid Join Query >

Select id, title from Select id, title from game ggame g, , star sstar s where where g.nameg.name = = s.titles.title;;

- 27 -

TableSpace : 정리

ALTIBASE 4.0 Tablespace

Memory 영역을 테이블 스페이스 개념으로 포함

일관성 있는 접근 방법 제공 (진정한 Hybrid 인터페이스)

기존 DRDBMS와의 쉬운 접근 및 호환성 보장

TABLESPACE

MemoryTable

DiskTable

응용 응용 응용

- 28 -

Layers

- 29 -

Layers : Resource Layer

Resource Layer


Recovery Layer(r)


Interface Layer(i)

Resource Layer(m) Memory/Buffer Mgr/Disk Mgr

ISSUE:DBMS 내의 효율적 자원관리

- 30 -

Layers : Resource Layer

Resource LayerDBMS 내의 자원 관리 (Memory, Disk)

Pointer or OID RID

MemoryManager Buffer

Manager

DiskManager

Memory Tablespace Disk Tablespace

- 31 -

Layers : Recovery Layer

Recovery Layer

Interface Layer(i) ISSUE :로그 디스크의 분리Restart Recovery 시점복구의 완전성

Application Layer(a)Transaction Layer(x,l)


Recovery Layer(r) Logging , Restart Recovery 관련

Resource Layer(m)

- 32 -


Recovery Layer

Restart recovery, rollback에 관련된 모든 동작을 관장

Logging, Replication API, redo, undo, File 관리

Problem: 로그 디스크를 어떻게 관리할 것인가?

- 동일 디스크 vs 분리 디스크 (consistency, repl)

A1 B2 C3 D4 E5 F6 commitSame

A1 B2 F6 commit

C3 D4

E5

D4가 사라지면?Split

하나의 트랜잭션이 메모리와 디스크를 모두 접근할 때

- 33 -


Recovery Layer

Restart Recovery 시점의 결정서버의 비정상 종료시 로그화일의 어느 부분부터 반영을 할

것인가?- 재구동 시간과 밀접한 관계 : 고객은 빠른 복구를 원함!- Checkpoint시 복구 시작 시점이 결정됨 보편적임

- Memory의 경우 CheckPoint시 고정됨.- Disk 의 경우 동적으로 가능함(Buffer Flush Thread)

해결 : 내부적으로 Checkpoint시 복구 시점을 각각 유지하고,redo시 최적의 방법으로 반영

Begin chk End chk

worst Not bad Best!

Memory Start Point

Disk Start Point

- 34 -


Recovery Layer

“완벽한 Restart Recovery를 확신할 수 있는가?”

완벽한 로깅 및 복구를 위해서는…- 모든 로깅 소스코드의 verify : 인간 지성의 한계

- 모든 로깅 조건에서의 테스트 : 모든 경우 테스트 가능?

Automatic Recovery Test Tool 개발

- 소스코드로부터 Recovery 시점의 DB화

- 자동화된 시나리오를 통한 Restart Recovery 검증

- 1000개의 Point의 경우 3일간의 테스트를 통해 모든 경우를

Verify 할 수 있음.

혁신적 Replication 기반 로깅 기법 (특허 출원중)

- Replication 환경에서 기존 DRDBMS에 비해 수배의 TPS

기대

- 35 -

Layers : Page Layer


Recovery Layer(r)


Interface Layer(i)

Resource Layer(m)

Page Layer

ISSUE :물리적 페이지 관리Page, Extend, Segment 구조

Physical Page Structure, Extent,Segment

- 36 -

Layers : Page Layer

Page Layer

Physical Data 관리 Layer

Memory Tablespace

- Used, Free Page List

- Fixed, Variable Page List

Disk Tablespace

- Page

- Extent : Page의 집합, Segment로의 할당 단위

- Segment : Extent의 집합

- Tablespace : 다수의 데이터 파일로 구성된 Segment의 집합

- 37 -

Layers : Page Layer

Page Layer

Free Page

Used Page

Extent

Table Index

Segment

TABLESPACE

- 38 -

Layers : Record Layer

Record Layer

Index Layer(n)Record Layer(c)

Page Layer(p)Recovery Layer(r)


Interface Layer(i)

Resource Layer(m)

ISSUE :Record의 저장 관리Catalog Table 관리

Logical 정보를담고있는 Record 구조

- 39 -


Record Layer

Logical data 관리 Layer

Fixed, Variable Record의 관리

Table 자체의 정보 유지

Memory Area

- Data Record (No Index : Not Persistent)

- Catalog Table : Table of Tables

Disk Area

- Data Record, Temp Record, Index Record, Undo

Record, TSS(Transaction Status Slot) Record

- No Catalog Table

- 40 -


Record Layer

“Disk 테이블 자체의 정보를 어디에 보관할 것인가?”M/D 어느 한 부분에서 일괄적으로 관리해야 함.

CATALOG TABLE

Memory Table

Disk Table

Memory Table

Table

TableSegment(Table)

Segment(Index1)

Segment(Index2)

TableSpace1 TableSpace2

Memory Tablespace Disk Area

- 41 -

Layers : Index Layer

Index Layer

Interface Layer(i) ISSUE :설계 목표구현 기법


Index Layer(n) 각종커서및인덱스

Record Layer(c)Page Layer(p)

Recovery Layer(r)Resource Layer(m)

- 42 -


Index Layer

전통적으로 DBMS에서 Recovery와 함께 가장 중요한 부분

복잡도가 가장 높은 모듈 : 동시성 제어와 Recovery의 혼재

목표

- “Update시 해당 인덱스만을 수정한다.”- “Node Versioning을 하지 않는다.”- “Unique Index에 대한 Update시 불필요한 Unique

Violation을 발생시키지 않는다.” Big Issue

Create table gamestar (id integer primary key);Insert into gamestar (1 ~ 10);Update gamestar set id = id +1;

- 43 -


Index Layer

Memory Index (No Logging)

- B+-Tree : No Node Versioning, No Node Latch,

Fast Traverse, Parallel Building

- T-Tree : Removed in Altibase-4

Disk Index (Logging)

- B+-Tree

• No Node Versioning, Only Node Latch in leaf

Node, No Latch Traverse, No Lock-Coupling

• SMO 발생시에도 Search Transaction은 No-

Latch Traverse 가능 기법 개발 (특허 출원 중)

SMO : Structure Modification Operation

- 44 -

Layers : Transaction Layer

Transaction Layer

Interface Layer(i) ISSUE :Record에 대한 SCN 처리Application Layer(a)

Transaction Layer(x,l) Transaction과 Lock Manager



- 45 -


Transaction Layer

Transaction Manager & Lock Manager

ALTIBASE 3의 구조를 대부분 차용

“commit시 입력된 Record가 SCN을 가지고 있어야 할 것인가?”

Memory Area : 모든 Record 가 Commit SCN을 유지

Disk Area : 유지할 수 없음.

- 트랜잭션 Commit시 변경된 모든 Record 를 재방문 하면서

SCN을 설정한다는 것이 넌센스

- 유지하고 있는 것과 동일한 방법을 모색해야 함.

- 이를 위해 TSS와 SSL(Start SCN List) 방법 개발

- 46 -


TSS & SSL

목표 : 빠른 commit 성능, 빠른 View의 결정

TSS(Transaction Status Slot)

- 트랜잭션의 Persistent 정보 유지 (TID, Commit SCN)

SSL(Start SCN List)

- 서버 내부의 모든 트랜잭션 SCN을 유지하는 리스트

Game

Tx30

20 10202

10333

TSS

END 35

SCNStateTID

commitSCNdata TID

Star 10333

data TID10334 RUN ??

10335 END 60

UnknownYES

- 47 -

Layers : Application Layer

Application Layer

Interface Layer(i)Application Layer(a) SM 응용 Thread (GC, Refine)

Transaction Layer(x,l)Index Layer(n)Record Layer(c)Page Layer(p)


- 48 -

Layers : Application Layer

SM Application Layer

SM 내부에 필요한 응용 Context

Memory Space

- Refine App : 구동시 Old Data Version 제거

- Index Rebuilder App

- Index Node GC App

- Data GC App

• 성능 및 효율성 중요 : 다수의 쓰레드가 병렬로 동작

Disk Space

- Data GC App 만 존재

• 성능보다 수행중인 트랜잭션 성능에 영향을 주지 않도록

설계

• 느리더라도 빠짐없는 Old Version의 Record 및

Index 리소스를 모두 회수할 수 있음.

- 49 -

Layers : Interface Layer

Interface Layer

Interface Layer(i) 상위QP 모듈에의해호출




- 50 -

Layers : Interface Layer

Interface Layer

Query Processor와의 인접 및 소통 경로

이 Layer 하부에 대해서는 절대 접근 불가능

Cursor API

- record retrieval

- Memory, disk에 관계없는 투명한 구조

Statement API

- 한 SQL을 구성하는 커서간의 상호관계를 정의(Stored

Procedure)

- 시스템 전체 SCN 정보의 집합 (GC, Replication 등)

- 51 -

Layers : 정리

Storage Manager의 Layer

8개의 Layer로 구성

각각의 Layer 별 명확하고 독립된 기능 관리

상호간의 의존성 제거 시스템 자체의 복잡도 낮아짐

복잡도에 따른 유지/보수에 대한 부담을 완화

- 52 -

Conclusions

- 53 -

Conclusions

Architecture 재설계를 통한 구조적 안정성 확보

Hybrid MM DBMS에 최적화된 MVCC 를 구현

사용자에게 투명하고, 우아한 데이터 저장 방법 제공

각 Layer에 최적화된 기법과 혁신적인 아이디어의 적용

높은 성능, 다양한 기능 제공

세계 최초의 Hybrid MM DBMS의 저장관리자 개발로

인한 원천기술 확보 달성

- 54 -

감사합니다

Documents

Hybrid MM DBMS ‘ALTIBASE 4’ Technical Features : Part I ... · MVCC에서 Record 버전 간의 시간순서를 결정하기 위한 방식 각 Record의 생성 시점(commit Time)을