hybrid mm dbms ‘altibase 4’ technical features : part ii ... · hybrid mm dbms ‘altibase 4’...
TRANSCRIPT
Hybrid MM DBMS Hybrid MM DBMS ‘‘ALTIBASE 4ALTIBASE 4’’Technical Features : Part IITechnical Features : Part II
Query ProcessorQuery Processor
(주)알티베이스 이경모[email protected]
- 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 -
감사합니다