History[01]

VanillaDB is an academic project developed by National Tsing Hua University starting from 2016. This project is launched for teaching and researching purpose, because most relational database systems nowadays conducts too many optimizations and are too complicated to understand for beginners. Database researchers can also test their new algorithms on it. As yet, VanillaDB becomes testbed for some research work, teaching project for some database courses, and the core engine for some advanced systems like ElaSQL.

Checkpoints[04]

VanillaDB supports non-quiescent checkpointing, i.e., it stops accepting new transactions but still allows current running transactions to continue when checkpointing is ongoing. The checkpointing will be done periodically, and active transactions at that time will be recorded in the log.

Concurrency Control[05]

VanillaDB allows several transactions running in parallel under control of strict two-phase locking protocol in multiple granularities: file, block and record. To cope with deadlocks, VanillaDB supports time-limit deadlock detection, which force transactions to rollback when they wait too long for a lock.

Data Model[06]

VanillaDB is a relational database to store data with user-defined schema. However, integrity constraints of relational model aren't well-supported, e.g., it doesn't support primary key.

Foreign Keys

Indexes[07][08]

VanillaDB supports both hash index and B-tree index, and users can specify which kind to user when creating index.

Isolation Levels[05]

VanillaDB supports transactions at different isolation levels concurrently, each transaction can specify its isolation level at creation time and the default transaction level is Serializable.

Joins[09][10]

VanillaDB only supports implicit joins in the FROM clause with Nested Loop Join, but it can also determine the join field in the WHERE clause to perform an Index Nested Loop Join.

Logging[04]

VanillaDB implements write ahead logging (WAL) to create physiological logs under No-Force/Steal buffering policy, and the logging granularity is value-level. Meanwhile, VanillaDB implements ARIES recovery algorithm to recover system from crash.

Query Compilation

Query Execution[10]

VanillaDB supports both pipelined (iterative) and materialized scanning. Specially, materialized scanning is used in ORDER BY and GROUP BY. When creating a query plan, VanillaDB will estimate the cost of scan trees and choose the best one.

Query Interface[11]

VanillaDB offer various interfaces to access, such as SQL interpreter, JDBC, stored procedures, and native query interfaces(Native API).

Storage Architecture[12]

VanillaDB is a disk-oriented database, block-level data is loaded into buffer manager before it can be manipulated. In VanillaDB, each transaction maintains its own buffer manager in memory.

Storage Model[13]

VanillaDB uses row-oriented store to store records, which means all fields inside a record are stored contiguously. These records can't span more than one page, and each page with records is organized as the slotted page.

Storage Organization[11][14]

VanillaDB stores databases as several files in existing file system, managed by the storage engine. Databases are separated by different directories, and each table with catalog and index information is a file under the database directory.

The storage engine offers both file-level interface and block-level interface to access the data. VanillaDB also implements two types of I/O mode that can be configured by users, including Java New I/O and Jaydio(direct I/O, Linux only).

Stored Procedures[11][15]

The official documentation claims that stored procedures are supported. But only the query interface of stored procedures is implemented, the execution part remains unimplemented now.

System Architecture[11]

VanillaDB runs on single node, which means CPU cores, memory and disk storage are all shared by transcations.

Views[11][09]

VanillaDB allows user to create views, but the length of a view definition is restricted to at most 100 characters. Views are only managed by Catalog Manager as metadata, that means only the properties of each view are stored, such as its definition and creator.