Crate reth_db

source ·
Expand description

reth’s database abstraction layer with concrete implementations.

The database abstraction assumes that the underlying store is a KV store subdivided into tables.

One or more changes are tied to a transaction that is atomically committed to the data store at the same time. Strong consistency in what data is written and when is important for reth, so it is not possible to write data to the database outside of using a transaction.

Good starting points for this crate are:

§Cursors and Walkers

The abstraction also defines a couple of helpful abstractions for iterating and writing data:

  • Cursors (DbCursorRO / DbCursorRW) for iterating data in a table. Cursors are assumed to resolve data in a sorted manner when iterating from start to finish, and it is safe to assume that they are efficient at doing so.
  • Walkers (Walker / RangeWalker / ReverseWalker) use cursors to walk the entries in a table, either fully from a specific point, or over a range.

Dup tables (see below) also have corresponding cursors and walkers (e.g. DbDupCursorRO). These should be preferred when working with dup tables, as they provide additional methods that are optimized for dup tables.

§Tables

reth has two types of tables: simple KV stores (one key, one value) and dup tables (one key, many values). Dup tables can be efficient for certain types of data.

Keys are de/serialized using the Encode and Decode traits, and values are de/serialized (“compressed”) using the Compress and Decompress traits.

Tables implement the Table trait.

§Overview

An overview of the current data model of reth can be found in the tables module.

Re-exports§

Modules§

  • Traits defining the database abstractions, such as cursors and transactions.
  • mdbxmdbx
    Bindings for MDBX.
  • reth’s static file database table import and access
  • Tables and data models.
  • test_utilstest-utils
    Collection of database test utilities
  • Database version utils.

Macros§

Enums§

Functions§

  • Creates a new database at the specified path if it doesn’t exist. Does NOT create tables. Check init_db.
  • Opens up an existing database or creates a new one at the specified path. Creates tables if necessary. Read/Write mode.
  • Check if a db is empty. It does not provide any information on the validity of the data in it. We consider a database as non empty when it’s a non empty directory.
  • Opens up an existing database. Read/Write mode with WriteMap enabled. It doesn’t create it or create tables if missing.
  • Opens up an existing database. Read only mode. It doesn’t create it or create tables if missing.