The Architecture of the RAQUEL DBMS

Transcription

1 The Architecture of the RAQUEL DBMS David Livingstone The Third Manifesto Implementers Workshop 2 nd 3 rd June 2011

2 Introduction Background Design Aim Overview Driver Interface (between App. & DBMS) RAQUEL DBMS Architecture Logical Memory Physical Details at :

3 Background 1. RAQUEL Relational Algebra DB programming language developed in 1990s, initially for teaching purposes. 2. Develop a Teaching Tool. Evolved into Develop a Third Manifesto PoC (Open Database Project). 3. Funded by NStar to build a RAQUEL PoC prototype to support Open Source development. 4. Currently re-factoring and documenting PoC prototype, to support further development.

4 Design Aims 1. To implement RAQUEL notation. S <--Retrieve R1 Join[ A ] R2 <--Insert { { A <-- 1; B <-- Jon } {. } {. } } RAQUEL statements are expressions. 2. To implement an Open, Building Block architecture. Build RAQUEL DBMS in different configurations, & easily replace modules with new ones. Core modules. Plug-in modules

5 Driver Application Statement Error/OK Relvalue(s) (optional) Driver RAQUEL Database Management System Interface Physical of the DB (including the Meta DB)

6 Architecture Logical Architecture Logical structure of DBMS wrt functionality. Traditional layered architecture. Core vs. plug-in modules. Memory Architecture Performance Objectives. DBMS Functional procedures vs. RAM procedures. Physical Architecture Implement logic under memory constraints. Functional Decomposition vs. Object Orientation.

7 Logical Architecture Input Parse Tree Meta Execution Data Protection Communication

8 Individual s Communication Input Parse Tree Meta Execution Data Protection Tokeniser Compactor Parser Tokeniser Compactor Parser

9 Reason for Compactor RAQUEL Text : Word Tokens : R1 Gen[ [ A > B ] R2 R1 Gen [ [ A > B ] R2 RAQUEL Tokens : R1 Gen[ [ A > B ] R2 Parse Tree : Gen[ [ A > B ] > R1 R2 A B

10 Individual s Communication Input Parse Tree Meta Execution Data Protection Tokeniser Compactor Parser Tokeniser Compactor Parser

11 Individual s Communication Input Parse Tree Meta Execution Data Protection Default Rewriter Semantic Checker Access Checker Expression Rewriter Constraint Handler Global Optimiser Local Optimiser

12 Individual s Communication Input Parse Tree Meta Execution Data Protection Meta Operator Data Definition

13 Individual s Communication Input Parse Tree Meta Execution Data Protection Physical Sequencer Relational Handler Handler Scalar Handler Scalar Type Scalar Type

14 Individual s Communication Input Parse Tree Meta Execution Data Protection Transaction Handler Logger

15 Individual s Communication Input Parse Tree Meta Execution Data Protection Translator Optimiser Driver

16 Statement Execution Process Pre-Processing Scalar Processing Relational Handler Relational Processing

17 Performance Objectives Memory Architecture 1. Efficient use of RAM. 2. Install DBMS on single computer or multiple networked computers. 3. Varying configurations of core modules. 4. Support using RAM as store. 5. Standard Driver Interface Comms in RAM. 6. Prevent plug-in module interfering with DBMS. 7. Dynamically add & remove plug-ins.

18 Memory Architecture Two orthogonal sets of procedures 1. Procedures which deliver DBMS functionality in standard DBMS RAM environment. 2. Procedures that provide standard DBMS RAM environment in variety of installation conditions. Caveats : 1. Procedures designed as single-threaded. Assume multi-threading can be applied later. 2. Multi-core CPUs. Like multi-threading?

19 1. Global RAM RAM Design Strategies Proc 1 Proc 2 Proc 3 Proc 4 N/W Proc 5 Data 1 Data 2 Data 2 CPU 1 CPU 2 2. Sandbox Plug-Ins 3. Dynamic Link Libraries for Plug-Ins

20 Physical Architecture Methodology : Functional Decomposition vs. Object Orientation Functional Decomposition corresponds to logical modules of layered logical architecture. functional decomposition to specify software modules. Continue to decompose if necessary. OO useful to create programmer-specified data types. useful data types to raise level of abstraction within procedures. Error Codes, RAQUEL Tokens. Plug-ins : User-defined Scalar Types, Physical Stores.

21 Design of Physical Architecture 1. Design object classes where relevant to raise level of abstraction of core modules. 2. Derive physical modules from logical modules : Purpose, interfaces, pre and post conditions, algorithms, module breakdown. May functionally decompose into sub modules. 3. Design Scalar Type & interfaces to DBMS. 4. Plug-Ins : Scalar types : values/variables are (token) objects. s : individual stores are objects.

22 Thanks for your attention. Questions? Comments?