Architecture

CoGaDB's Query Interfaces

CoGaDB has a modular design, meaning it has a layered architecture, where an upper layer is implemented using the preceding layer. The most advanced way to launch queries in CoGaDB is to use the SQL interface. CoGaDB's SQL parser creates a logical query plan, consisting of operators from the Logical Operator based API. Using the logical query plan (Logical Operator based API), HyPE creates a physical query plan (which is executable) by choosing for each operator in the logical query plan a suitable physical operator from the Physical Operator based API. The Physical Operator based API provides a special interface, so HyPE can be used as execution engine. Internally, the physical operators have to execute a certain operation using the algorithm HyPE selected. This algorithms are performed in the Function based API, which contains functions that are capable of processing complex operations (e.g., selections with arbitrary combined filter predicates or groupbys with multiple aggregation functions). The complex functions are implemented using the Internal API, which consists of highly optimized primitives using libraries such as TBB or Thrust.

SQL Interface

• Pass queries in SQL-92 via an interactive shell
• Automatic plan generation, optimization and operator scheduling
• Utility commands not included in SQL
• Recommended API for creating queries in CoGaDB

Logical Operator based API

• Build queries via API
• Uses HyPE as execution engine, scheduling and query optimization is done automatically (implements the mapping layer for HyPE)
• All available operators can be found in the namespace CoGaDB::query_processing::logical_operator

Physical Operator based API

• Build queries via API
• Uses HyPE as execution engine, however, scheduling and query optimization is done manually (bypasses the mapping layer for HyPE)
• All available operators can be found in the namespace CoGaDB::query_processing::physical_operator

Function based API

• Build queries via API
• HyPE is not used for execution, so a manual execution of operators (including scheduling and query optimization) is neccessary, for hand-tuned queries (not recommended)
• Calls to CoGaDB's actual database operators
• All available functions can be found in the class CoGaDB::BaseTable

Internal API

• Internal functions that implement CoGaDB's actual database operators
• Work on single columns either on CPU or GPU
• Each operator has a well defined task it is optimized for (e.g., filter a column, sort a column, join two columns) and returns a list of tuple identifiers (TIDs), which are positionlists
• Functions are distributed in different modules, they can be found in the class CoGaDB::ColumnBaseTyped and CoGaDB::gpu::GPU_Operators.

Operators

We differentiate between to types of operators. Processing operators perfrom computations on the actual data and can be executed on the CPU or the GPU. Management Operators decompose complex Operations (e.g., filtering a table according to multiple and arbitrary complex selections or sorting a table after multiple columns).

Processing Operators

• Selection,
• Sort
• Join
• Groupby (ColumnAlgebra, AggregationFunctions)

Management Operators

• Projection (in a column stores it is just skipping some columns while keeping others)