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 ratio of 1:1.

Data Model

Object-Relational

Concurrency Control

Multi-version Concurrency Control (MVCC)

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.

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.

Joins

Nested Loop 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, giving a huge boost in performance over the traditional CPU Database.

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. This is an easily scalable process, and the importance of that cannot be overestimated. 10 billion rows could be distributed over 100 GPUs and achieve exactly the same cycle time as 1 billion rows on 10 GPUs.

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 defines four levels of transaction isolation. The most strict is Serializable, which is defined by the standard in a paragraph which says that any concurrent execution of a set of Serializable transactions is guaranteed to produce the same effect as running them one at a time in some order. The other three levels are defined in terms of phenomena, resulting from interaction between concurrent transactions, which must not occur at each level. The standard notes that due to the definition of Serializable, none of these phenomena are possible at that level.