20 releases
0.4.1 | May 12, 2022 |
---|---|
0.3.15 | May 9, 2022 |
0.3.14 | Jan 18, 2022 |
0.3.13 | Dec 8, 2021 |
0.3.10 | Jul 8, 2021 |
#2309 in Database interfaces
Used in 2 crates
16KB
269 lines
BoringDB
A SQLite-based, single-process, key-value database.
You want boringdb if:
- You want high performance somewhat approaching that of databases like sled and RocksDB
- You don't need SQL, multiprocess support, or the other cool features of SQLite
- You want SQLite's proven reliability
Method Of Operation
BoringDB stores key/value pairs into byte vectors (Vec<u8>
).
Examples
We have various usage examples here.
To run any of the examples, execute:
cargo run --example example_name_goes_here
Cache architecture
We have a writeback cache supporting the following operations:
- Insert with batch number
- Read key with fallback closure
- Remove dirty keys as an iterator-like object that returns batches.
lib.rs
:
BoringDB
A SQLite-based, single-process, key-value database.
You want boringdb if:
- You want high performance somewhat approaching that of databases like sled and RocksDB
- You don't need SQL, multiprocess support, or the other cool features of SQLite
- You want SQLite's proven reliability
A note on durability
By default, boringdb has eventual durability: database state is guaranteed to be consistent even in the face of arbitrary crashes, and transactions are guaranteed to have "serializable" semantics. However, after a crash the database may be slightly out of date, usually by a fraction of a second.
To avoid this behavior, use the Dict::flush method to manually force synchronization with disk. Note that this comes with a fairly severe performance cost.
Method Of Operation
BoringDB stores key/value pairs into byte vectors (Vec<u8>
).
Examples
Examples can be found in the examples directory
Dependencies
~24MB
~459K SLoC