History[04][03][05]

BadgerDB was initially a persistent key-value store intended to replace DgraphDB’s dependency on RocksDB, since RocksDB is written in C++ and requires the use of Cgo to be called via Go. It was a (side) project lead by Manish Rai Jain, a chief decision maker at Dgraph. The project github repository received its first commit January 26, 2017. As the project progressed, it upgraded from being a key-value store to a database system, on October 16, 2017.

Checkpoints[06][01]

The user has the option to toggle the flag SyncWrites, to determine how immediately an update is propagated to disk. If SyncWrite is false, writes may not sync to disk immediately and the database might have to be closed before the changes are propagated to disk. In addition to changes being propagate to disk on Close(), changes are also propagated when MaxTableSize is reached.

Compression[03][07]

BadgerDB uses delta encoding to reduce the size of keys, to further reduce the size of the LSMs. Also, during a read, a fingerprint of the key is stored rather than the key itself to also save space.

Concurrency Control[07]

Badger supports ACID transactions and Multi-Version Concurrency Control with Snapshot Isolation. Badger acquires locks on directories when accessing data, so multiple processes cannot open the same database at the same time.

Data Model[06][03][05]

Badger’s underlying functionality is a key-value store. The user can choose to store additional meta-data with the key-value pair for use when processing that data.

Hardware Acceleration[03]

Badger uses LSMs, which were designed around hard drives, since random I/Os are slower than sequential ones, and LSMs allow for sequential background read/writes rather than random ones.

Indexes[03]

BadgerDB supports a LSM tree, where keys are stored in the LSM and values are store in a write-ahead log called a value log. Since key tend to be smaller than values, this allows the system to maintain a smaller LSM tree. The LSM make sure to maintain a sorted order, making range queries easier to process, as well.

Isolation Levels[05][07]

BadgerDB supports snapshot isolation. Badger also has read-only transactions (called Views), that ensures a consistent view of the database system, and that will not include changes made by an uncommitted transaction at the start of this transactions. With read-write transactions, if a conflict occurs, the transaction will written with an error notifying the user of a conflict, giving the user the option to retry the transaction.

Logging[03][08]

BadgerDB seems to support Write-Ahead Logging (WAL), and after a crash, it iterates over recent updates (logged in disk) and re-applies them. To prevent iterating over the entire WAL, Badger maintains a pointer to the latest log to have been written to disk.

Query Execution[06][09][03]

BadgerDB is inspired by the simplicity of LevelDB and supports Get, Set, Delete, and Iterate functions. Multiple updates can be batched-up into a single transaction, allowing the user to do a lot of writes at a time.

Query Interface[03][05][02]

The query interface for BadgerDB is in Go since the system was originally created to provide a key-value store that can easily be accessed through Go without having to go through Ggo.

Storage Architecture[03][08]

BadgerDB is an in-memory DBMS, that supports larger-than-memory databases by writing to disk. Disk is also used to make the BadgerDB persistent and resilient.

Storage Model[03]

The LSM writes the initial in-memory updates in memtables. Once those are full, they are moved over to immutable memtables that are eventually written to disk.

Storage Organization[03]

BadgerDB uses a sorted LSMs to support a key-value store storage organization.

Stored Procedures

System Architecture[05]

The documentation states that BadgerDB is an embeddable database management system but does not go into detail.

Views