mirror of
https://github.com/aljazceru/turso.git
synced 2025-12-18 17:14:20 +01:00
b4932340f4
And specifically, the amount of things we don't have implemented to even think of that. It's mostly about tracking commit dependencies which allow speculative reads/ignores of certain versions, as well as making sure that in the commit phase, we validate visibility of all versions read, as well as that our scans took into account all data. If some version appeared after the transaction began, and it was not taken into account during its scans, it is considered a "phantom", and it invalidates the transaction if we strive for serializability.
MVCC for Rust
This is a work-in-progress the Hekaton optimistic multiversion concurrency control library in Rust. The aim of the project is to provide a building block for implementing database management systems.
Features
- Main memory architecture, rows are accessed via an index
- Optimistic multi-version concurrency control
- Rust and C APIs
Experimental Evaluation
Single-threaded micro-benchmarks
| Operations | Throughput |
|---|---|
begin_tx, read, and commit |
2.2M ops/second |
begin_tx, update, and commit |
2.2M ops/second |
read |
12.9M ops/second |
update |
6.2M ops/second |
(The cargo bench was run on a AMD Ryzen 9 3900XT 2.2 GHz CPU.)
Development
Run tests:
cargo test
Test coverage report:
cargo tarpaulin -o html
Run benchmarks:
cargo bench
Run benchmarks and generate flamegraphs:
echo -1 | sudo tee /proc/sys/kernel/perf_event_paranoid
cargo bench --bench my_benchmark -- --profile-time=5
References
Larson et al. High-Performance Concurrency Control Mechanisms for Main-Memory Databases. VLDB '11
Paper errata: The visibility check in Table 2 is wrong and causes uncommitted delete to become visible to transactions (fixed in commit 6ca3773).