Checkpoints

Non-Blocking

VanillaDB supports non-quiescent checkpointing, which means 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 saved in the log.

Views

Virtual Views

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.

Isolation Levels

Read Committed Serializable Repeatable Read

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.

Concurrency Control

Two-Phase Locking (Deadlock Detection)

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.

Query Execution

Tuple-at-a-Time Model Materialized Model

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.

Logging

Physiological Logging

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.

Stored Procedures

Not Supported

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.

Foreign Keys

Not Supported

Storage Organization

Sorted Files

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).

Query Compilation

Not Supported

Indexes

B+Tree Hash Table

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

Data Model

Relational

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

System Architecture

Shared-Everything

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

Query Interface

Custom API SQL Stored Procedures

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

Storage Architecture

Disk-oriented

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.

Joins

Nested Loop Join Index Nested Loop Join

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.

Storage Model

N-ary Storage Model (Row/Record)

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.