System Architecture

Shared-Nothing

BlazingSQL worker nodes push information to each other whenever required. There is a notion of a distributed cache, and nodes can ask each other for cached data lake data.

Data Model

Relational

BlazingSQL

Compression

Dictionary Encoding Delta Encoding Run-Length Encoding Bit Packing / Mostly Encoding

BlazingSQL supports compressing and decompressing directly on the GPU. It accepts a variety of input formats such as Apache Parquet, BlazingDB Simpatico (GPU-compressed distributed files), and GDF (GPU dataframes built on Apache Arrow). Data is then sent to the GPU compressed.

Storage Organization

Log-structured

BlazingSQL appears to be log-structured as it did not previously have support for update and delete, but this is uncertain.

Indexes

Not Supported

BlazingSQL does not appear to support indexes.

Query Interface

SQL

BlazingSQL exposes a Python connector for executing SQL commands.

Concurrency Control

Not Supported

It is unclear what forms of concurrency control are in place for BlazingSQL.

Joins

Hash Join

BlazingSQL supports hash joins, e.g. on strings. It is not clear what other join types are supported.

Isolation Levels

Snapshot Isolation

BlazingSQL supports Snapshot Isolation, it is unclear if other options are supported.

Query Execution

Vectorized Model

BlazingSQL operations are vectorized on the GPU (SIMD).

Storage Architecture

In-Memory

Stored Procedures

Not Supported

As of BlazingSQL 1.3, stored procedures do not appear to be supported.

Storage Model

Decomposition Storage Model (Columnar)

BlazingSQL is a column-store. To execute a query, it compresses and transmits relevant columns to the GPU. On the GPU, data is represented as a GPU DataFrame (GDF). GDFs are built on top of Apache Arrow, which is a columnar in-memory format.

Hardware Acceleration

GPU

Views

Virtual Views

BlazingSQL 1.3 supported the CREATE VIEW command. It is unclear if the views are virtual or materialized.