History

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 conduct too many optimizations and are too complicated to understand for beginners. VanillaDB can also be used for database researchers to test their new algorithms.

As yet, VanillaDB has became the testbed for some research work, teaching project for some database courses, and the core engine for some advanced database systems like ElaSQL.

Checkpoints[03]

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

Concurrency Control[04]

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 forces transactions to rollback when they wait too long for a lock.

Data Model[05]

VanillaDB is a relational database to store data with user-defined schema. However, some integrity constraints of relational model are not fully supported (e.g., primary keys).

Foreign Keys

Indexes[06][07]

VanillaDB supports both hash index and B-tree index, and users can specify which one to use in CREATE INDEX clause.

Isolation Levels[04]

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[08][09]

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[03]

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 database system from crash.

Query Compilation

Query Execution[09]

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 estimates the cost of scanning trees and chooses the best one.

Query Interface[10]

VanillaDB offers various query interfaces, such as SQL, JDBC, stored procedures, and native query interfaces.

Storage Architecture[11]

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

Storage Model[12]

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

Storage Organization[10][13]

VanillaDB stores databases as several files in existing file system, managed by the storage engine. Databases are separated into 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. It 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[10][14]

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

System Architecture[10]

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

Views[10][08]

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