Concurrency Control
Multi-version Concurrency Control (MVCC)
Since Brytlyt is based on PostgreSQL, it inherits its multi-version concurrency control scheme.
Hardware Acceleration
Brytlyt supports the filtering, sorting, aggregating, grouping and joining tables by GPU acceleration. Brytlyt stores data in CPU memory in vectorized columns (not in tuples/rows) to optimize parallel processing across all available GPUs. When the operation begins to be executed, the data is moved as from CPU memory to GPU memory, and returned back to CPU memory when the operation is completed.
Brytlyt supports JOIN operations directly on the GPU. It breaks the data into blocks and then distributes the blocks to various GPU cores used for searching (horizontal partitioning).
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
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, because the nested looping is not a good choice to be parallelized. Note that the GPU have cores grouped in chunks and each chunk executes the same instructions, the nested looping could not fully uses the GPU feature for more parallelism.
Approach
Brytlyt claims to apply the patent-pending method, which recursively separates rows containing a hit from rows that do not, to solve the challenge. In details, Brytlyt breaks the data into blocks and then distributes the blocks to the many cores used for searching. It begins from a croase-grained block and then digs into into the fine-grained block until the joining operation is finished.
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. In traditional single CPU environment, it requires 2000 loops to complete, but in GPU environment, it only takes roughly 1 loop time. After the searching stage, the empty blocks (no hit) are discarded, and the process repeated with the remaining blocks (hit at least one). Then the whole process is done over and over until only the relevant blocks remain. According to the experiment, 10 billion rows could be distributed over 100 GPUs and achieve exactly the same cycle time as 1 billion rows on 10 GPUs.
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.
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.
Storage Architecture
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.
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.
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. However, sometimes the executed relation could not fit into the GPU memory entirely, Brytlyt still needs to transfer the data from CPU to GPU frequently when processing a large relation.
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.
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.
