VoltDB의 전신인 H-Store의 내부구조를 보여주는 논문, The End of an Architectural Era (It’s Time for a Complete Rewrite) 관전포인트 : Relational Model의 데이터를 Transaction의 ACID프로퍼티를 만족하면서 어떻게 Scalable하게 여러 노드에서 분산, 고속처리하는지? 요약 : (1) Lock, Latch 다 갖다 버리고 Optimistic Concurrency Control을 하자! (2) Logging도 갖다 버리자! (Trasaction Abort를 위해 메모리상에 Undo Log기록 허용) (3) CPU의 Core 1개 당 Single Thread로 동작하는 프로세스 즉, Site를 띄우자! (4) Stored Procedure 1개 = Transaction 1개. 시스템에서 실행될 트랜잭션의 Table접근 패턴을 분석해서 Transaction을 분류하자! Single Sited, One-Shot, Two-Phase, Strongly Two-Phase, Steril. (5) Database생성시에 Stored Procedure 리스트, 즉 실행될 Transaction List를 다 받아서 데이터를 어떻게 여러 노드에서 분산처리할지 계획을 세운다. (6) Optimistic Concurrency Control시 Transaction Abort가 많아지면 Basic->Intermediate->Advanced Strategy로 실행전략을 바꾸어가며 Tranasction이 Abort될 가능성을 낮추어나간다. 자동샤딩 : (1) Read-Only테이블은 모든 노드에 Replication 실시. (2) 특정 컬럼의 데이터를 모든 노드에 Replication 실시(잘 이해 안됨). (3) 그 외 테이블의 데이터는 N개의 노드에 Horizontal Partitioning하여 저장. (4) 쿼리가 들어오면, 이러한 사항들을 고려하여 쿼리 플랜을 만들고 각 노드에 속한 Site로 쿼리 실행 명령을 보낸다. 그리고는 플랜을 보낸 노드가 결과를 취합한다. 독후감 : (1) ACID 프로퍼티를 만족하기 때문에 안정성은 높아지겠지만, Transaction 1개를 Stored Procedure 1개로 구성해야 한다는 점과 같은 제약조건 때문에 사용자가 쓰기에는 불편할 것 같다. (실제로 VoltDB 3.0에서는 Stored Procedure안쓰고도 Tranasction날릴 수 있는 Ad-Hoc Query제공) (2) Disk에 Redo Log를 기록하지 않는다는데, Cluster에 속한 모든 전원 나가면 데이터 유실 가능하다는 것을 가정하는 것인지 궁금하다. cs-cs.yale.edu/homes/dna/vldb07hstore.pdf
Posted on: Fri, 07 Jun 2013 09:49:32 +0000
Trending Topics
Recently Viewed Topics
© 2015