Backend
First, we need an actual database implementation.
cuprate-database's traits allow abstracting over the actual database, such that any backend in particular could be used.
This page is an enumeration of all the backends Cuprate has, has tried, and may try in the future.
heed
The default database used is heed (LMDB). The upstream versions from crates.io are used. LMDB should not need to be installed as heed has a build script that pulls it in automatically.
heed's filenames inside Cuprate's data folder are:
| Filename | Purpose |
|---|---|
data.mdb | Main data file |
lock.mdb | Database lock file |
heed-specific notes:
- There is a maximum reader limit. Other potential processes (e.g.
xmrblocks) that are also reading thedata.mdbfile need to be accounted for - LMDB does not work on remote filesystem
redb
The 2nd database backend is the 100% Rust redb.
The upstream versions from crates.io are used.
redb's filenames inside Cuprate's data folder are:
| Filename | Purpose |
|---|---|
data.redb | Main data file |
redb-memory
This backend is 100% the same as redb, although, it uses redb::backend::InMemoryBackend which is a database that completely resides in memory instead of a file.
All other details about this should be the same as the normal redb backend.
sanakirja
sanakirja was a candidate as a backend, however there were problems with maximum value sizes.
The default maximum value size is 1012 bytes which was too small for our requirements. Using sanakirja::Slice and sanakirja::UnsizedStorage was attempted, but there were bugs found when inserting a value in-between 512..=4096 bytes.
As such, it is not implemented.
MDBX
MDBX was a candidate as a backend, however MDBX deprecated the custom key/value comparison functions, this makes it a bit trickier to implement multimap tables. It is also quite similar to the main backend LMDB (of which it was originally a fork of).
As such, it is not implemented (yet).