RisingLight doesn't support transactions.
A user table is cut horizontally as RowSets, and then vertically into column files. Data within one column are stored continuously in multiple column files.
RisingLight uses vectorized volcano model (aka. chunk at a time) for query execution. Furthermore, some arithmetic expressions have special SIMD implementation to make execution faster.
In RisingLight, each table corresponds to a merge-tree on disk. Inside each merge-tree, there are multiple RowSets. Each RowSet is composed of multiple column files. Each column file contains multiple blocks, which is the minimal unit of the cache. RowSets can be sorted or unsorted. For sorted RowSets, the sparse index file will record the first cell of each block, so as to support efficient range scan.
RisingLight stores data on disk. Data are organized on disk using merge-tree structure. There are multiple RowSet directories inside the RisingLight database directory, where each RowSet belongs to a user table, organized in a merge-tree. Inside each RowSet directory, there are multiple column files and column index files.
RisingLight provides consistent snapshot by using merge-tree structure in the storage engine. The manifest file stores a full list of files of the database. Every write from users will produce a group of files called RowSet, and the information of the RowSet will be added to the manifest file.
RisingLight stores data in a relational way.
The minimal encoding unit of RisingLight is data blocks, about 64KB in size, containing multiple cells in a table. RisingLight supports run-length block encoding.
In RisingLight, different executors can be running on different threads.