Hybrid MM DBMS Hybrid MM DBMS ‘‘ALTIBASE 4ALTIBASE 4’’Technical Features : Part IITechnical Features : Part II

Query ProcessorQuery Processor

(주)알티베이스 이경모leekmo@altibase.com

- 2 -

CONTENTS

1. Problems & Goals2. Query Executor3. Query Optimizer4. Performance5. Conclusions

- 3 -

Problems & Goals

- 4 -

Problems – 기존 연구

Multi-Level Storage DBMS-<Michael Stonebraker> (1991)

Multi-Level Storage DBMS

Memory Table

DiskTable

Memory Buffer

ArchiveTable

Memory Buffer

DiskBuffer

Memory Layer

Disk Layer

Archive Layer(Tape, Juke Box)

- 5 -

Problems – Storage Manager

MMDBMS와 DRDBMS의 통합- Storage Manager의 통합 문제

Integration of Object Identifier

Management of System Catalog Objects

Special Buffer Management

Index Management

Integration of Recovery Mechanism

Integration of Concurrency Control

- 6 -

Problems – Query Processor

MMDBMS와 DRDBMS -Query Processor의 근본적 차이

Object Identifier

Pointer Itself OID(RID)

BufferManagement

N/A Limited Buffer

Join Methods One-Pass Algorithms Multi-Pass Algorithms

Main Cost CPU Disk

Index Selection

MinimizeRecord Access

MinimizeDisk I/O

Cost Factor T(R), V(R.a) T(R), V(R.a), B(R), M

Query Processor

Item MMDBMS DRDBMS

Executor

Optimizer

T(R ) : 테이블의 레코드 수 B(R ) : 테이블의 Page 수V(R.a) : 컬럼의 Value Cardinality M : Memory Buffer 수

- 7 -

Problems – Query Processor

Architecture의 통합-. Hybrid MM DBMS 개발 복잡도 >> MMDBMS + DRDBMS

메모리

상주

테이블

디스크

상주

테이블

StorageManager

QueryProcessor

DBMS의 외적 통합

StorageManager

QueryProcessor

More Query ProcessorMMDBMS DRDBMS

메모리

상주

테이블

StorageManager

QueryProcessor

디스크

상주

테이블

StorageManager

QueryProcessor

- 8 -

Goals – Transparent Architecture

ALTIBASE 4 Architecture-. Transparent Architecture

-. 구조화, 체계화를 통한 seamless implementation

메모리

상주

테이블

디스크

상주

테이블

Integrated Storage Manager

Integrated Query Processor

More

Query P

rocesso

r

Integrated Query Executor

Integrated Query OptimizerMemory QueryProcessor Disk

Storage

Manager

Hybrid MM DBMS

- 9 -

Goals – Memory Table Query Processing

Memory Table에 대한 성능 저하 우려Disk 질의 처리 모듈과의 통합

Hybrid(Memory + Disk) 질의 처리

Disk 고려로 인한 MMDBMS의 장점 상실

대전제 : ALTIBASE는 MM DBMS목표 1 : 성능 저하가 발생해서는 안됨

목표 2 : ALTIBASE 3 보다 우수한 질의 처리 성능

목표 3 : 기존 고객의 우려 해소

- 10 -

Goals – Disk Table Query Processing

DRDBMS 의 기능 수용기존 상용 DBMS 사용자들의 높은 기대치

10년 이상의 상용 DBMS 기술의 수용

Memory Table 처리의 성능 저하 요소 제거

대전제 : 대용량 지원목표 1 : Memory 질의 처리와 동일한 기능 제공

목표 2 : 상용 DBMS에 준하는 성능

목표 3 : 대용량 처리를 위한 안정성 확보

- 11 -

Goals – Hybrid Query Processing

Hybrid Query 처리Hybrid Query : Memory, Disk Table을 모두 접근하는 질의

Example)

SELECT * FROM MemTable, DiskTable

WHERE MemTable.col = DiskTable.col;

INSERT INTO DiskTable SELECT * FROM MemTable;

대전제 : Transparent Processing• 목표 1 : Memory, Disk 구분 없는 SQL 사용

• 목표 2 : Transparent Architecture

• 목표 3 : 고객의 유연한 시스템 구성

- 12 -

Goals – 유연한 시스템 구성

고객정보

계좌정보

거래정보

OO 은행 :대부분 최근 3개월 조회??

고객정보

계좌정보

거래정보

ALTIBASE 4 의 도입

고객정보

계좌정보

ALTIBASE 4 의 도입

이전거래정보

최근거래정보

ALTIBASE 4 의 도입

이전거래정보

최근거래정보고객정보

계좌정보

SELECT ( (SELECT COUNT(*)

FROM 최근거래정보WHERE account = 1 )

+(SELECT COUNT(*)

FROM 이전거래정보WHERE account = 1 ) )

FROM dummy;

“너무 어렵다 ^^;”

“아~ VIEW가 있었지”

CREATE VIEW 거래정보AS SELECT *

FROM 최근거래정보UNION ALL SELECT *FROM 이전거래정보;

거래정보

SELECT COUNT(*)FROM 거래정보WHERE account = 1;

“이러면 Index를 못쓰는데?”

SELECT COUNT(*)FROM 거래정보WHERE account = 1;

질의 최적화에 의한 처리 개념

SELECT COUNT(*)FROM ( SELECT *

FROM 최근거래정보WHERE account = 1UNION ALLSELECT *FROM 이전거래정보WHERE account = 1 ) 거래정보;

“아~~, 쓸만하군”

INSERT INTO 이전거래정보SELECT * FROM 최근거래정보WHERE date < ‘2004/09/01’;

DELETE FROM 최근거래정보WHERE date < ‘2004/09/01’;

“이 동안 조회를 하면오류가 발생할 수 있겠군, 쩝”

BEGIN TRANS;INSERT INTO 이전거래정보

SELECT * FROM 최근거래정보WHERE date < ‘2004/09/01’;

DELETE FROM 최근거래정보WHERE date < ‘2004/09/01’;

END TRANS;

“아~~ Transaction, 쓸만하군 ”

ALTIBASE 4 를 이용한

시스템 구성 예

‘1번구좌’의 총 거래 회수?

다음달: 3달전 데이터는

“최근거래정보” 에서 제거

테이블의 분할 :

서비스 개발의 어려움이 없음

- 13 -

Query Executor

- 14 -

Query Processing 단계

SQL statement

Parsing

Validation

Parse Tree

Parsing : Syntax AnalysisValidation : Semantic AnalysisParse Tree 생성

Execution

Query Executor : Plan Tree를 구성하는 각 Plan Node가Storage Manager를 이용하여 질의 처리

SQL statement 입력

Optimization

Plan Tree

Query Optimizer : Parse Tree를분석하여 최적화된 실행 계획 수립

Plan Tree(Execution Plan) 생성

- 15 -

Integrated Query Executor – 근본적 난제

MMDBMS와 DRDBMS : Executor의 차이점Plan Node : Executor를 대표하는 주요 모듈

(Execution Node, Physical Operator)

주요 차이점 : 레코드 관리, 중간 결과 관리, Join Methods

레코드 관리MMDBMS : Pointer를 이용한 관리

DRDBMS : RID를 이용한 관리

중간 결과 관리MMDBMS : Memory Temp Table

DRDBMS : Disk Temp Table

- 16 -

Query Executor Architecture

Integrated Query Executor ArchitectureMemory, Disk 구분의 최소화

모듈화, 구조화

Storage Manager

Record Manager

Memory Disk

Temp Table Manager

Memory Disk

Execution Layer (24 Plan Nodes)

SCAN PROJ FILT JOIN

SORT HASH AGGR MGJN

BUNI SITS VIEW ***

Mathematics Layer

Data TypeManager

OperatorManager

LanguageManager

Integrated Query Executor

- 17 -

Tuple-Set Query Processing

질의 처리 방식Materialization 방식

Pipelining 방식

JOIN

SCANT1

SCANT2

Pipelining Processing

Tuple-Set Query ProcessingPipelining의 보다 모듈화 된 개념

Plan Node간의 dependency 제거JOIN

SCANT1

SCANT2

Tuple-Set

Tuple-Set Processing

- 18 -

Tuple-Set Processing 효과

Tuple-Set Processing의 장점MMDBMS 의 질의 처리 성능 향상

극한의 모듈화

새로운 실행 기법 개발 용이

DRDBMS 기법 도입의 용이

Multi-PassSORTJOIN

IndexNested Loop

JOIN

One-Pass HASHJOIN

HASH

JOIN

Plan SORT

JOIN

SORTSCAN

JOIN

Plan

- 19 -

Join Method의 차이

MMDBMS 와 DRDBMS의 Plan Node대부분의 Plan Node

: 레코드 관리, 중간 결과 관리를 제외하고

MMDBMS와 DRDBMS의 차이가 없음

Join Method : DRDBMS의 경우 매우 다양한 기법 사용

Join Method의 차이MMDBMS : Buffer Miss가 없음

: One-Pass 계열의 알고리즘

DRDBMS : Buffer Miss를 고려

: One-Pass, Multi-Pass 계열의 알고리즘

Disk Table 처리를 위해서는

Multi-Pass Join Algorithm의 도입이 필수

- 20 -

Join Method의 확장

STORE

JOIN

Plan

Full Store Nested JoinALTIBASE 4의 Join Method

<H. Garcia-Molina> (2000)

Nested Loop 계열

: Full Nested, Full Store Nested,

: Index Nested, Anti Outer Nested

Sort-based 계열

: One-Pass, Multi-Pass Sort Join

Hash-based 계열

: One-Pass, Multi-Pass Hash Join

Merge-based 계열

: Index, Sort, Child-Merge를 이용한

9가지 Merge Join Method

총 17 * 2 가지의 Join Method

: 10개 => 34개로 확장

“Merge Join” Plan Node 하나만 추가

Multi-Pass Hash Join

HASH

JOIN

HASH

SCAN

MGJN

SCAN

Indexed Merge Join

SORT

MGJN

SORT

Sort Merge Join

- 21 -

ALTIBASE 4 Query Executor

Integrated Query ExecutorMMDBMS와 DRDBMS의 Executor를 완전히 통합

Tuple-Set Query Processing에 기반

체계화, 구조화를 통한 통합 난제 극복

Query Executor의 기능 및 성능기존 MMDBMS 성능 유지

DRDBMS의 질의 처리 기법의 도입

Disk, Memory 구분 없는 질의 처리

철저한 구조화, 모듈화ALTIBASE 3 : 122,000 line

ALTIBASE 4 : 141,000 line

- 22 -

Query Optimizer

- 23 -

Query Optimizer Concepts

Query Optimizer주어진 Parse Tree를 각종 정보를 이용하여 최적화된

실행 계획을 작성

GraphManager

Plan TreeManager

Graph(logical operator)Parse TreePlan Tree

(physical operator)

Query Optimizer

- 24 -

Query Optimizer Architecture

Query Optimizer Architecture모듈화, 체계화

Disk, Memory 구분 없음

Graph Manager (12 logical operators)

Plan Tree Manager

Plan TreeGenerator

DependencyGenerator

Integrated Query Optimizer

ProjectionSelection Join

Grouping Sorting ***

Non Critical Path Critical Path Mgr

NormalizerPredicateClassifierStatistics Selectivity

Predicate ManagerKey

Range

- 25 -

Integrated Query Optimizer – 근본적 난제

Query Optimizer의 중요성Optimizer로 인한 성능 저하의 파장

-. MMDBMS : 0.1 sec 1.0 sec

-. DRDBMS : 1.0 sec 10 sec

기존 MMDBMS : 특정 질의의 경우 DRDBMS보다 느린 성능

Disk Table 처리를 위해서는 대대적 개혁 필요

Cost Estimation의 난제MMDBMS : Access Cost 중심(CPU bound)

DRDBMS : Disk Cost 중심 (IO bound)

Hybrid Query : Join Cost의 평가

-. Mem ☓ Mem, Disk ☓ Disk,

-. Disk ☓ Mem, Mem ☓ Disk ☓ Disk, . . .

- 26 -

실시간 통계 정보

실시간 통계 정보통계 정보를 실시간으로 유지

한건의 Record 변경에도 통계 정보 변경

부하 없는 통계 정보 유지

To Do : 분석 통계 정보

ALTIBASE 4의 실시간 통계 정보의 종류<J. Ullman> (2000)

T(R) 테이블 R의 Total 레코드 수

B(R) 테이블 R의 디스크 Block 수

V(I) 인덱스 I의 Value cardinality

M Memory 버퍼 수

V(R.a) 컬럼 R.a의 Value cardinality

MN(R.a) 컬럼 R.a의 MIN 값

MX(R.a) 컬럼 R.a의 MAX값

ALITBASE 3 :T(R)로 충분

- 27 -

실시간 통계 정보의 활용

실시간 통계 정보의 활용보다 정확한 실행 계획 작성이 용이

Predicate의 Selectivity 계산

Cost Estimation

Size Estimation

ExampleSELECT COUNT(*) FROM 고객정보

WHERE age = 30 AND branch = ‘여의도’;

통계 정보 : V(age) = 60, V(branch) = 300

age = 30 : 1/V(age) = 1/60

branch = ‘여의도’ : 1/V(branch) = 1/300

branch Index를 사용

- 28 -

실시간 통계 정보의 구축

실시간 통계 정보의 구축별도의 부하가 없도록 설계

인덱스를 활용한 실시간 통계 정보

다른 정보로부터 통계 정보 추론

><

<Record의 삽입 Index on R.a

MN(R.a) MX(R.a)(=) 부재 : V(R.a)++;

- 29 -

Transparent Cost Estimation

ALTIBASE 4의 비용 계산 방법하나의 비용 계산으로 통일

Memory, Disk Query의 구분 없이 하나의 계산식 사용

Cost 계산 개념 : Access Cost + Disk Cost

Example

Access 선택을 위한 Index Cost 계산

Join 선택을 위한 Sort Join Cost 계산

= T(R) * selectivity + B(R) * (1 + Log selectivity / Log T( R ) )

Memory Table :B(R) = 0

= 3 * B(R) + T(R) Log T(R) + T(L) * {Log T(R) + T(R) * ( 1 + B(R) )}

- 30 -

Join Processing

Join Ordering

여러 테이블들의 Join 순서를 결정

질의 처리 성능에 가장 큰 영향(Critical Path)

Algorithm 비교

기법 Factors Search Space

Full Ordering Cost N !

Dynamic Programming Cost, Pruning N ! 이하

Join Permutation Cost, Join Relation 2*(N-1)

Join Greedy Algorithm Join Selectivity, Cost 1

Ordered FROM Order 1

ALTIBASE 3

Join Greedy Algorithm 채택

<E. Wong> (1976)

Join Selectivity를 이용하여

Join Order만 결정

Join Cost 비교를 통해

Join Method 및 방향 결정

Join Size = T(L) * T( R) * selectivity

Join Selectivity = Join Size / (T(L) + T(R))

- 31 -

Optimization Tips

Optimization Tip

학술적으로 매우 다양한 연구

수학적 동치, 조건적 동치를 이용한 성능 향상

개념적으로 질의에 조건을 추가, 변경, 삭제

Example

Multiple Key-Range : 수학적 동치, 조건 변경

Transform NJ : 조건적 동치, 조건 추가

WHERE age IN ( 12, 24, 36 ) => WHERE age = 12 OR age = 24 OR age = 36

조건 : Account.id 와 History.id 가 모두 NOT NULLWHERE Account.id IN ( SELECT id FROM History ); =>WHERE Account.id IN

( SELECT id FROM History WHERE id = Account.id );

- 32 -

Optimization Tips - Selection

Ex) Key Filter

<모든 DRDBMS>

MMDBMS에는 필요 없는 기법

Index Key에 대한 Filter 검사를

통해 Data Page에 대한 접근 감소

Selection 관련 Tips

Fixed, Variable Key-Range

Multiple Key-Range

Fixed, Variable Key-Filter

Filter Ordering

CNF Only Predicate

SCAN Limitation

Preprocessing Constant Filter

Amelioration of

Constant Expression

Use of Join Index

Use of Composite Index

Key-Range for List

Key-Range for

Multi-Column List

Key Range : c1 > 0

Index Page

Key Filter : c2 = 1

DataPage

Filter : c3 = 1

* Index on (c1, c2)* WHERE c1 > 0 AND c2 = 1 AND c3 = 1

- 33 -

Optimization Tips – Sorting

Sorting 관련 Tips

Indexable ORDER BY

LIMIT ORDER BY

(Top 10 Query)

Use of ORDER BY Indicator

Ex) LIMIT ORDER BY

<Top-k Research>

Web 의 발달로 인한

Top-k Query에 대한 연구 활발

예) 거래액이 가장 많은 10명의 고객

SELECT id

FROM 거래정보

GROUP BY id

ORDER BY SUM(money) DESC

LIMIT 10;

k개의 공간만을 이용하여 Sorting

전체 Sorting과의 비용 비교

N Log N >=

k Log k + (N – k) Log k

- 34 -

Optimization Tips – Distinction

Ex) Indexable Distinction

Index를 이용하여 Sorting 부하를

제거한 후 Distinction

Preserved Order 개념 사용 :

단순히 Index 사용 가능 여부가 아닌

Preserved Order의 개념으로 판단

Distinction 관련 Tips

Sort-Based Distinction

Hash-Based Distinction

Indexable Distinction

Elimination of

Same Distinct Expression

* SELECT DISTINCT T1.i1, T2.i1 FROM T1, T2WHERE T1.i1 = T2.i1;

Selection(T1)

Join

Selection(T2)

Distinction

Preserved Order : T2.i1

Preserved Order의 사용 : T1.i1 - T2.i1

Preserved Order의 요구 : T1.i1 - T2.i1

Projection

- 35 -

Optimization Tips – Grouping

Grouping 관련 Tips

Sort-Based Grouping

Hash-Based Grouping

Indexable GROUP BY

Indexable MIN, MAX

Indexable

Distinct Aggregation

Push Projection Effect

of Grouping

COUNT(*) Optimization

on COMMIT READ

COUNT(*) Optimization

on REPEATABLE READ

Ex) Indexable

Distinct Aggregation

Index를 활용한 Column에 대한

Distinct Aggregation의 처리

조건적 수학 동치, 개념적 질의 변형

* SELECT COUNT(DISTINCT col)FROM T1;

개념적 질의 변형

* SELECT COUNT(*)FROM ( SELECT DISTINCT col

FROM T1 );

- 36 -

Optimization Tips – 기타

View 관련 Tips

Push-Selection for VIEW

View Materialization

of Multiple Same VIEW

Use Preserved Order of VIEW

Inner Join 관련 Tips

Push-Selection for Inner Join

Push-Selection

for Left Outer Join

Push-Selection

for Full Outer Join

Use Anti Outer Join

Hierarchy 관련 Tips

Extract LEVEL Predicate

Ignore CONNECT BY Predicate

By Constant Filter

SET 관련 Tips

Push-Selection for SET

Multiple Set Union

Store Small Query SET

- 37 -

Optimization Tips – Sub-Query

Sub-Query 관련 Tips

Eliminate Target of

EXISTS, UNIQUE Sub-Query

Eliminate Quantify Rule

Transform NJ

Amelioration of

Constant Sub-Query

Constant Sub-Query Filter

Fully, Partially, Timely

In-Variant Area of Sub-Query

Late Filtering

Key-Range for

Comparison Sub-Query

Key-Range for Quantify

Comparison Sub-Query

Store And Search

Store MIN-MAX And Search

Ex) Invariant Area of Sub-Query

<Won Kim>

Sub-Query의 분류: Type N, J, A, NJ

Dependency 개념을 이용한

Invariant Area 개념의 확장

JOIN

SCAN SCAN

PROJ

JOIN

JOINSCAN

SCAN SCAN

Sub Query

Variant Area

Timely Invariant Area

Partially Invariant Area

- 38 -

ALTIBASE 4 Query Optimizer

Integrated Query OptimizerMMDBMS와 DRDBMS의 Optimizer를 완전히 통합

비용 계산 방법의 통합을 통한 난제 극복

Hybrid Query의 최적화 난제 극복

Query Optimizer의 기능 및 성능다양한 실시간 통계 정보를 이용한 정확한 비용 계산

MMDBMS의 최적화 기법을 대폭 개선

DRDBMS의 최적화 기법 및 다양한 최적화 Tip의 도입

철저한 구조화, 모듈화ALTIBASE 3 : 45,000 line

ALTIBASE 4 : 55,000 line

- 39 -

Performance

- 40 -

실험 환경

TPC-Hwww.tpc.org

Decision Support Benchmark Test Set

22개의 질의로 구성

복잡한 질의 처리 성능

Table 구성

Memory Disk Hybrid

테이블명 레코드 수 Query Query Query

REGION 5 Memory Disk Memory

NATION 25 Memory Disk Memory

SUPPLIER 10,000 Memory Disk Memory

CUSTOMER 150,000 Memory Disk Memory

PART 200,000 Memory Disk Memory

PARTSUPP 800,000 Memory Disk Memory

ORDERS 1,500,000 Memory Disk Disk

LINEITEM 6,001,215 Memory Disk Disk

- 41 -

TPC-H 질의 구성 예 (Query 5)Memory Query

Disk Query

Hybrid Query

SELECTn_name,sum(l_extendedprice * (1 – l_discount)) as revenue

FROMcustomer,orders,lineitem,supplier,nation,region

WHERE c_custkey = o_custkeyAND l_orderkey = o_orderkeyAND l_suppkey = s_suppkeyAND c_nationkey = s_nationkeyAND n_regionkey = r_regionkeyAND r_name = ‘ASIA’AND o_orderdate >= date’01-JAN-1994’AND o_orderdate <

add_months(date’01-JAN-1994’, 12)

GROUP BY n_nameORDER BY revenue desc;

customer,orders,lineitem,supplier,nation,region

customer,orders,lineitem,supplier,nation,region

customer,orders,lineitem,supplier,nation,region

Red : Memory TableBlue : Disk Table

- 42 -

Memory, Disk, Hybrid Query 성능

실험 환경

SUN Fire 880, SunOS 5.8

CPU: 1.2GHz 8개, Memory: 16G, Disk: 2 Tera

비고

Hybrid, Disk, 상용 DBMS 성능은 2번째 수행 결과

Buffer Miss 영향을 최소화

TPC-H 질의 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11

ALTIBASE 3 31.81 0.10 4.12 1.34 15.15 6.47 4.19 9.27 12.39 6.58 0.58ALTIBASE 4 Memory 29.75 0.13 5.10 1.56 16.60 2.18 4.61 1.32 13.80 3.95 0.27ALTIBASE 4 Hybrid 151.70 0.12 12.89 3.74 32.29 7.93 12.45 2.63 26.96 11.03 0.27ALTIBASE 4 Disk 151.25 0.33 13.02 3.75 58.19 7.92 15.14 3.30 46.79 13.59 1.79상용 DBMS 275.84 0.38 38.68 7.36 48.53 66.87 44.78 10.26 45.51 14.14 2.45

TPC-H 질의 Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22

ALTIBASE 3 3.24 6.97 1.27 0.92 3.86 0.08 19.24 0.61 7.32 70.09 1.27ALTIBASE 4 Memory 3.19 8.12 1.34 0.83 4.62 0.04 19.85 0.09 0.77 36.09 1.22ALTIBASE 4 Hybrid 9.99 21.06 2.18 2.42 4.61 0.12 81.28 0.18 1.38 98.94 1.40ALTIBASE 4 Disk 9.94 21.92 3.51 5.65 11.65 0.14 81.73 0.29 2.05 102.18 2.74상용 DBMS 35.86 37.58 3.47 19.65 16.18 0.33 111.93 1.33 6.29 92.73 4.21

- 43 -

ALTIBASE 4 성능 비교

TPC-H 성능 비교(12 ~22)

0

2

4

6

8

10

12

14

16

18

20

Q12 Q13 Q14 Q15 Q16 Q17 Q18 Q19 Q20 Q21 Q22

성능

배수

TPC-H 성능 비교 (1 ~ 11)

0

2

4

6

8

10

12

14

16

18

20

Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11

성능

배수

30 배

21 배 23 배

- 44 -

Conclusions

- 45 -

ALTIBASE 4 Query Processor

Integrated Query ProcessorMemory, Disk Query Processor의 완벽한 통합

철저한 구조화, 모듈화를 통한 통합 난제 극복

다양한 Disk 기반 Algorithm 수용

ALTIBASE 4 Query Processor보다 향상된 Memory Query 처리

상용 DBMS에 준하는 Disk Query 처리

Memory, Disk, Hybrid Query의 투명한 처리

- 46 -

ALTIBASE 4 – Paradigm의 변화

Paradigm의 변화변화 1 : DRDBMS의 등장 (1980)

-. 데이터와 응용의 분리로 서비스 개발 속도 향상

-. 성능을 요하는 분야에 부적합

변화 2 : MMDBMS의 등장 (2000)

-. 데이터를 모두 메모리에 저장하여 서비스 성능의 향상

-. 대용량 처리에 부적합

변화 3 : Hybrid MM DBMS의 등장 (2005)

-. ALTIBASE 4 Hybrid MM DBMS

-. 성능, 대용량, 운영 문제를 모두 해결

-. 매우 유연한 시스템 개발 환경 제공

- 47 -

ALTIBASE 4 – Paradigm의 변화

WHERE WE GO?

MMDBMS

DRDBMS

Hybrid DBMS

ALTIBASE 1 (2000)

ALTIBASE 2 (2001)

ALTIBASE 3 (2003)

ALTIBASE 4 (2005)Hybrid MM DBMSSpeed

Size

- 48 -

ALTIBASE 4 Hybrid MMDBMS

ALTIBASE Version 4혁신적인 아이디어를 바탕으로 한

세계 최초의 상용 Hybrid MM DBMS

ALTIBASE Version 1, 2, 3의 개발 경험을 기반으로 한

기술적 안정성 확보

System Software 개발의 기술적 자립 성취

Michael Stonebraker 의 아이디어가 현실로 이루어짐.

성능, 대용량, 안정성을 모두 보장하는 새로운 DBMS

DBMS 분야의 새로운 Paradigm 제시

- 49 -

감사합니다