Brytlyt

Brytlyt is a GPU-accelerated DBMS built on top of Postgres.

History

Brytlyt is GPU accelerated database that is based on PostgreSQL 9.4 and uses a Massively Parallel Processing (MPP) architecture to provide horizontal scale out for handling large amounts of data. Brytlyt is first released in 2016, now located at the milestone 2.0 (Dec.2018) and it has a long-term roadmap to version 5.0. But now, Brytlyt has rearchitected the GPU database to be a storage engine that sits underneath MariaDB, the fork of the MySQL database. This wiki is still based on the PostgreSQL version which has been released publicly.

Concurrency Control

Multi-version Concurrency Control (MVCC)

Note that the Brytlyt database is derived from PostgreSQL. According to the lecture given by Brytlyt team, the team does not change the logic in the concurrency control level. It applies Multi-version Concurrency Control for data consistency. For MVCC, not only the current status but also previous values of data are visible to the transaction, which provides transaction isolations. The primary advantage of MVCC overlocking is that the writing operation won't conflict with the reading operation on the same block of data. Thus, MVCC reduces the lock contention to achieve high throughput.

Data Model

Object-Relational

Foreign Keys

Supported

Hardware Acceleration

GPU

1. The database operation accelerated by the CPU must be parallelizable, and in many cases parallelizing an operation is not trivial. Relational operations like filtering, sorting, aggregating, grouping and even joining tables are all possible on GPU. 2. Data usually resides in CPU memory in vectorized columns to optimize parallel processing across all available GPUs. The data is moved as needed to GPU memory for both mathematical and spatial calculations, and the results then returned to CPU. 3. Brytlyt develops a unique approach to accelerate JOINS by GPU. by devising a patent-pending method that recursively separates rows containing a hit from rows that do not. It breaks the data into blocks and then distributes the blocks to the many cores used for searching. 4. Disk-IO bottleneck and PCIe bottleneck are two challenges in the development of the GPU-accelerated database. In order to avoid PCIe bottlenecks and use the full capabilities of CPU and GPU, brytlyt suggests having a GPU:CPU ratio of 1:1.

Isolation Levels

Read Uncommitted Read Committed Serializable Repeatable Read

Note that the Brytlyt database is derived from PostgreSQL. According to the lecture given by Richard Heyns, the CEO of Brytlyt, Brytlyt team does not change the logic in the isolation level. The SQL standard of PostgreSQL defines four levels of transaction isolation, among them serializable is the most strict isolation level.

Joins

Hash Join

## Challenge The traditional approach for running joins on CPU and is not well suited for the hundreds of thousands of cores in a GPU system. Since GPU’s have cores grouped in chunks, with each chunk running the same instructions, most GPU Databases have a tough time with join operations. ## Approach Brytlyt has approached the parallelism challenge by devising a patent-pending method that recursively separates rows containing a hit from rows that do not. It breaks the data into blocks and then distributes the blocks to the many cores used for searching. ## Example For example, a dataset of 400,000 rows would be broken into blocks of 200 rows on a 2000-core GPU. Each GPU core then runs its own search on its own block of data in parallel with all the other cores, which provides a huge boost in performance over the traditional CPU Database. The empty blocks are discarded, and the process repeated with the remaining blocks. Then the whole process is done over and over until only the relevant blocks remain. In this example, 10 billion rows could be distributed over 100 GPUs and achieve exactly the same cycle time as 1 billion rows on 10 GPUs.

Logging

Physical Logging

Note that the Brytlyt database is derived from PostgreSQL. According to the lecture given by Richard Heyns, the CEO of Brytlyt, Brytlyt team does not change the logic in the concurrency control level. PostgreSQL supports a WAL mechanism that we can support reverting to any time instant covered by the available WAL data. It simply installs a prior physical backup of the database, and replay the WAL log just as far as the desired time. Additionally, the physical backup doesn't have to be an instantaneous snapshot of the database state — if it is made over some period of time, then replaying the WAL log for that period will fix any internal inconsistencies.

Query Execution

Tuple-at-a-Time Model Vectorized Model

In Brytlyt, not all things are executed on the GPU. The Tuple-at-a-Time model is much more suitable for the CPU execution, however, the GPU acceleration relies on the vectorized method to increase the parallelism. Please refer to the join section for more information about vectorization method used in Brytlyt.

Query Interface

PL/SQL

Brytlyt has adopted the open source database PostgreSQL within which to implement its intellectual property. With PostgreSQL comes the full suite of SQL and programmatic SQL functionality. SQL is the Lingua Franca of the data processing world.

Storage Architecture

Hybrid

Brytlyt is a disk-oriented database, where the table and index are majorly stored on the disk. But it also fully schedules the memory structure between CPU host memory and GPU memory to accelerate the query and avoid the extra overhead led by the data transferring. ## GPU Data Source GPUs improve performance only when data is in the main system memory; hence it’s much better to keep hot data in main memory, instead of keeping hot data in the disk. ## Optimized GPU-CPU Memory Control The performance of GPU-accelerated database highly depends on the data transfer efficiency. And the data transfers can be significantly accelerated by keeping ‘semi-hot data’ in host memory and hot data in GPU RAM. But since the GPU RAM is smaller (GBs) vs. host memory (TBs), data has to be still transferred over x16 PCIe bus. ## PCIe Data Transfer Topic To avoid PCIe bottlenecks and use the full capabilities of CPU and GPU, it is better to have a ratio of 1:1. This would allow optimal processing for a given operation. Otherwise, the "N-to-1" relation leads to the transfer bottleneck.

Storage Model

N-ary Storage Model (Row/Record)

Note that the Brytlyt database is derived from PostgreSQL and Brytlyt team does not change the logic in the storage model where the DBMS stores all of the attributes for a single tuple contiguously as a N-ary storage model.

System Architecture

Shared-Everything

Brytlyt is a forked branch of the PostgreSQL with additional Brytlyt GPU Manager and Nvidia GPUs embedded in the database engine. It doesn't support multi-master shared-storage but cold standby failure for shared-storage. To further explain the problem, Brytlyt supports four levels of parallelism from the system side, level 1: Coordinating multiple machines level 2: Coordinating multiple GPUs level 3: Data streaming on and off the device level 4: Each GPU is a parallel machine

Views

Virtual Views

In Brytlyt, "CREATE VIEW" defines a view of a query. The view is not physically materialized. Instead, the query is run every time the view is referenced in a query. Also, the name of the view must be distinct from the name of any other view, table, sequence, index or foreign table in the same schema.

Brytlyt Logo
Website

http://www.brytlyt.com/

Tech Docs

https://www.brytlyt.com/documentation/

Developer

Brytlyt

Country of Origin

US

Start Year

2013

Project Type

Commercial

Written in

C, C++

Supported languages

C, C++, Delphi, Java, Perl, Python, Tcl

Derived From

PostgreSQL

Operating Systems

Linux, OS X, Windows

Licenses

Proprietary