Hybrid MM DBMS ALTIBASE 4 4 Technical Features : Part I Storage Manager ( 주 ) 알티베이스김성진 sjkim@altibase.com
-2- CONTENTS 1. Problems & Goals 2. SM Architecture 3. Concurrency Control 4. TableSpace 5. Layers 6. Conclusions
Problems & Goals -3-
Problems & Goals -4- 혁명적인 DBMS 의개발 누구도가보지않은미지의대륙 => What s it? Goal : Hybrid MM DBMS = MMDB + DRDB - Hybrid Car 다양한상황에서최적의구동방법선택 응용 응용 응용 ALTIBASE 4 메모리상주테이블 디스크상주테이블
Problems & Goals Storage Manager 입장에서의도전과제 성능 기능 - MMDB : 기존의성능을저해하지않아야함 - DRDB : 현존하는상용 DRDBMS 능가 - MMDB : ALTIBASE 3 의지원기능모두수용 - DRDB : 대용량 Disk 기반테이블제공 안정성 - 상용 DRDBMS 에필적할만큼의품질요구 - 고객의비명 : 으악.. 또죽었어... -5-
Problems & Goals Problems 개발자신념의문제 - 과연이게가능한목표인가? - 시장에서성공할만한제품인가? 기술적문제 - 어떤 Architecture 로설계를해야하나? - 어떤방식의동시성제어를사용해야하나? - 적절한복구기법이존재는하는건지? - Replication 도되어야해!( 상위관리자 ) - 새로운백업정책도세워야하는데 ( 혼잣말 ) - 절대서버가죽어서는안된다 (CEO) - T T;; -6-
Architecture -7-
Storage Manager Architecture 기존 Architecture C++ class 단위의모듈구성 Object Oriented 설계기법에맞는구조 문제점 System Software 에이러한형태가바람직한가? Interface Lock Transaction Page Record Index Table Recovery -8-
Storage Manager Architecture Layered Architecture A hierarchy of Layers Layer : 동일혹은유사한기능적집합 단위 간결, 직관적 한 Layer 는바로하위의 Layer 를호출, 그반대는허용하지않음 Depth의숫자에따른성능Tradeoff 예 ) 1968, THE O/S by Dijkstra Structure of the THE Operating System -9-
Storage Manager Architecture 완화된 Layered Architecture 목적 : Performance 향상 Depth 에따른 Overhead 단점극복 상위 Layer 는임의의하위 Layer 호출 하위 Layer 는 transparent callback 을통해상위 Layer 를 호출 Advantages Layer 및모듈의독립성보장 : Complexity Unit Test 가용이 - 하위 상위로의단계적통합테스트가능 - Unit Test SM Regression Test Server Regression Test -10-
Storage Manager Architecture -11- Layered Architecture of ALTIBASE 4/SM (8 Layer) Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) 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
Concurrency Control -12-
Concurrency Control : Introduction -13- What is Concurrency Control? How to guarantee the consistency of data? What Happen? GAMESTAR 34 Read Modify Transaction 1 Transaction 2
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 GAMESTAR 34 Exclusive Mode Read Modify Transaction 1 Transaction 2-14-
Concurrency Control : SVCC -15- SVCC(Single Version Concurrency Control) 최악의상황 TX1 TX2 GAMESTAR 34 Read Exclusive Mode Modify Transaction X TX3 TX4 TX5 TX6
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 없음 높은성능 GAMESTAR 34 FOREVER 34 Exclusive Mode Read Modify Transaction 1 Transaction 2-16-
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 -17-
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 Old New GAMESTAR FOREVER New FOREVER Old GAMESTAR Data Page Data Page Undo Area Out-place (RID 변경 ) In-Place(RID 유지 ) -18-
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) Tx begin A Insert A B Update B C Update C Delete A 100 B 110 C 120 delete 140 Statement view A 105 B 115 C 120 No Record 160 Transaction view A 105 A 105 A 105 A 105-19-
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 연산에의함 ) 일정시간이지나도완전한회수는쉽지않음. 해당트랜잭션의성능에영향을미침 -20-
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 -21-
Concurrency Control : 정리 Concurrency Control 의선택 SVCC(Single Version Concurrency Control) - 전통적인 Lock 기법 - 서로다른종류의 Tx 발생시성능저하가능성 MVCC (Multi Version Concurrency Control) - 연산간의충돌최소화 높은성능 ALTIBASE - MVCC 기법중각부분의장점을채택 Memory Out-Place, Disk In-Place 최적의 Garbage Collection 방식 빠른 Statement View 제공 고기능 Index 처리기법구현 -22-
TableSpace -23-
TableSpace : 개념 TableSpace : an allocation of space in the database that can contain persistent schema objects. 현존하는대부분의 DRDBMS에서지원 ALTIBASE 4부터지원 기존응용프로그램의호환성 DRDBMS 사용자의쉬운접근성 Schema 설계및유지보수의편의성 -24-
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 -25-
TableSpace : example -26- Use Case Create Tablespace myspace Extent SIZE 320K DATAFILE /alti/dbs/data1.tbs SIZE 100M AUTOEXTEND ON NEXT 10K MAXSIZE 1000M; Create table game (name char(32)) [tablespace sys_tbs_memory]; Insert into game values( gamestar gamestar ); Create table star (id integer, title char(32)) tablespace myspace; Create Index staridx on game (id) tablespace myspace; Insert into star values(1, gamestar ); <Memory + Disk Hybrid Join Query > Select id, title from game g, g star s where g.name = s.title;
TableSpace : 정리 ALTIBASE 4.0 Tablespace Memory 영역을테이블스페이스개념으로포함 일관성있는접근방법제공 ( 진정한 Hybrid 인터페이스 ) 기존 DRDBMS와의쉬운접근및호환성보장 응용응용응용 TABLESPACE Memory Table Disk Table -27-
Layers -28-
Layers : Resource Layer -29- Resource Layer Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) ISSUE: DBMS 내의효율적자원관리 Memory/Buffer Mgr/Disk Mgr
Layers : Resource Layer Resource Layer DBMS 내의자원관리 (Memory, Disk) Pointer or OID RID Memory Manager Buffer Manager Disk Manager Memory Tablespace Disk Tablespace -30-
Layers : Recovery Layer -31- Recovery Layer Interface Layer(i) ISSUE : Application Layer(a) 로그디스크의분리 Restart Recovery 시점 Transaction Layer(x,l) 복구의완전성 Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) Logging, Restart Recovery 관련
Layers : Recovery Layer Recovery Layer Restart recovery, rollback에관련된모든동작을관장 Logging, Replication API, redo, undo, File 관리 Problem: 로그디스크를어떻게관리할것인가? - 동일디스크 vs 분리디스크 (consistency, repl) Same A1 B2 C3 D4 E5 F6 commit Split A1 B2 E5 F6 commit C3 D4 D4 가사라지면? 하나의트랜잭션이메모리와디스크를모두접근할때 -32-
Layers : Recovery Layer -33- Recovery Layer Restart Recovery 시점의결정 서버의비정상종료시로그화일의어느부분부터반영을할것인가? - 재구동시간과밀접한관계 : 고객은빠른복구를원함! - Checkpoint 시복구시작시점이결정됨 보편적임 - Memory 의경우 CheckPoint 시고정됨. - Disk 의경우동적으로가능함 (Buffer Flush Thread) 해결 : 내부적으로 Checkpoint 시복구시점을각각유지하고, redo 시최적의방법으로반영 Memory Start Point Begin chk End chk Disk Start Point worst Not bad Best!
Layers : Recovery Layer Recovery Layer 완벽한 Restart Recovery를확신할수있는가? 완벽한로깅및복구를위해서는 - 모든로깅소스코드의 verify : 인간지성의한계 - 모든로깅조건에서의테스트 : 모든경우테스트가능? Automatic Recovery Test Tool 개발 - 소스코드로부터 Recovery 시점의 DB화 - 자동화된시나리오를통한 Restart Recovery 검증 -1000개의Point의경우3일간의테스트를통해모든경우를 Verify 할수있음. 혁신적 Replication 기반로깅기법 ( 특허출원중 ) - Replication 환경에서기존 DRDBMS에비해수배의 TPS 기대 -34-
Layers : Page Layer -35- Page Layer Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) ISSUE : 물리적페이지관리 Page, Extend, Segment 구조 Physical Page Structure, Extent,Segment
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의집합 -36-
Layers : Page Layer -37- Page Layer Free Page Used Page Extent Table Index Segment TABLESPACE
Layers : Record Layer -38- Record Layer Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) ISSUE : Record 의저장관리 Catalog Table 관리 Logical 정보를담고있는 Record 구조
Layers : Record Layer 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 -39-
Layers : Record Layer -40- Record Layer Disk 테이블자체의정보를어디에보관할것인가? M/D 어느한부분에서일괄적으로관리해야함. CATALOG TABLE Table TableSpace1 TableSpace2 Memory Table Table Segment (Table) Segment (Index2) Memory Table Segment (Index1) Disk Table Memory Tablespace Disk Area
Layers : Index Layer -41- Index Layer Interface Layer(i) ISSUE : 설계목표 Application Layer(a) 구현기법 Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) 각종커서및인덱스
Layers : Index Layer 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; -42-
Layers : Index Layer 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 -43-
Layers : Transaction Layer -44- Transaction Layer Interface Layer(i) ISSUE : Application Layer(a) Record에대한 SCN 처리 Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) Transaction 과 Lock Manager
Layers : Transaction Layer 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) 방법개발 -45-
Layers : Transaction Layer TSS & SSL 목표 : 빠른 commit 성능, 빠른 View의결정 TSS(Transaction Status Slot) - 트랜잭션의 Persistent 정보유지 (TID, Commit SCN) SSL(Start SCN List) - 서버내부의모든트랜잭션 SCN을유지하는리스트 data YES commit SCN TID Tx 30 data Unknown TID TID 10333 TSS State SCN END 35 10334 RUN?? Game 20 10202 Star 10333 10335 END 60-46-
Layers : Application Layer -47- Application Layer Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) SM 응용 Thread (GC, Refine)
Layers : Application Layer -48- 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 리소스를모두회수할수있음.
Layers : Interface Layer -49- Interface Layer Interface Layer(i) Application Layer(a) Transaction Layer(x,l) Index Layer(n) Record Layer(c) Page Layer(p) Recovery Layer(r) Resource Layer(m) 상위 QP 모듈에의해호출
Layers : Interface Layer Interface Layer Query Processor와의인접및소통경로 이 Layer 하부에대해서는절대접근불가능 Cursor API - record retrieval - Memory, disk에관계없는투명한구조 Statement API - 한 SQL을구성하는커서간의상호관계를정의 (Stored Procedure) - 시스템전체 SCN 정보의집합 (GC, Replication 등 ) -50-
Layers : 정리 Storage Manager 의 Layer 8 개의 Layer 로구성 각각의 Layer 별명확하고독립된기능관리 상호간의의존성제거 시스템자체의복잡도낮아짐 복잡도에따른유지 / 보수에대한부담을완화 -51-
Conclusions -52-
Conclusions Architecture 재설계를통한구조적안정성확보 Hybrid MM DBMS 에최적화된 MVCC 를구현 사용자에게투명하고, 우아한데이터저장방법제공 각 Layer 에최적화된기법과혁신적인아이디어의적용 높은성능, 다양한기능제공 세계최초의 Hybrid MM DBMS 의저장관리자개발로 인한원천기술확보달성 -53-
감사합니다 -54-