History[01]

The project started in 2018 as a replacement for RocksDB running inside of CockroachDB.

Concurrency Control[03]

Pebble achieves concurrency during its commit pipeline, by using a 'commit queue'. In order to commit a batch, Pebble must first write the batch to its WAL and then add it to a memtable. The commit queue allows Pebble to synchronize writes to the WAL first. Then batches can be concurrently added to their memtables.

Data Model[04]

Pebble uses two types of keys - user keys suited for the user API and 'Internal Keys' which are composed of the user key, a sequence number, and a value signifying the key type. The Internal Key type is used, since the LSM tree requires versioning with keys.

Foreign Keys

Indexes[05]

Pebble uses a LSM tree to store writes. All records are stored in batches, which in turn are stored in in-memory memtables and sstables. To support indexing, there is a separate skiplist implementation based on RocksDB. It stores offsets to the records within their batch in order to perform reads. Furthermore, batches themselves are transformed into levels of the LSM tree (with temp sequence numbers set to be the most recent sequence).

Isolation Levels[03]

Since Pebble uses a LSM tree with a sequence number per log, this provides a very easy way to generate snapshots of the database by sequence number.

Joins

Logging[03]

Pebble uses a write-ahead logging (WAL) infrastructure. Batches are first written to the WAL, and then inserted into a memtable. Pebble purposefully maps each WAL file to a memtable.

Query Execution

Query Interface[04]

Pebble emulates the custom RocksDB API for querying keys/values.

Storage Architecture[05]

Pebble primarily uses sstables on disk which store various things such as internal keys/values and range tombstone deletions. It also has memtables, which temporarily store committed records before they are written to a sstable.

Storage Model[05]

Pebble uses sstables and memtables for storage.

Storage Organization

System Architecture