History[03][04]

BadgerDB was initially a persistent key-value store intended to replace DgraphDB’s dependency on RockDB, since RockDB 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, and as the project progressed, it upgraded from being a key-value store to a database system.

Compression[03][05]

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

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

Badger’s underlying functionality is an efficient key-value store.

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. To allow efficient access, the LSM make sure to maintain a sorted order, making range queries easier to process, as well.

Isolation Levels[04][05]

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

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 Interface[03][04][02]

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

Storage Architecture[03][06]

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

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

Stored Procedures

I do not think BadgerDB supports stored procedures.

System Architecture[04]

Views

I do not think BadgerDB supports views.