VSDB
VSDB is a 'Git' in the form of a KV database.
Based on the powerful version control function of VSDB, you can easily give your data structure the ability to version management.
Make everything versioned !!
Highlights
- Support Git-like verison operations, such as:
- Create countless branches and merge them to their parents
- Rolling back a 'branch' to a specified historical 'version'
- Querying the historical value of a key on the specified 'branch'
- Most APIs is similar as the coresponding data structures in the standard library
- Use
Vecxjust likeVec - Use
Mapxjust likeHashMap - Use
MapxOrdjust likeBTreeMap
- Use
- ...
Examples
Suppose you have a great algorithm like this:
struct GreatAlgo {
a: Vec<...>,
b: BTreeMap<...>,
c: u128,
d: HashMap<...>,
e: ...
}
Simply replace the original structure with the corresponding VSDB data structure, and your algorithm get the powerful version control ability at once!
struct GreatAlgo {
a: VecxVs<...>,
b: MapxOrdVs<...>,
c: OrphanVs<u128>,
d: MapxVs<...>,
e: ...
}
impl GreatAlgo {
fn version_create(&self, name: &str) {
self.a.version_create(VersionName(name)).unwrap();
self.b.version_create(VersionName(name)).unwrap();
self.c.version_create(VersionName(name)).unwrap();
self.d.version_create(VersionName(name)).unwrap();
...
}
fn branch_create(&self, name: &str) {
self.a.branch_create(BranchName(name)).unwrap();
self.b.branch_create(BranchName(name)).unwrap();
self.c.branch_create(BranchName(name)).unwrap();
self.d.branch_create(BranchName(name)).unwrap();
...
}
...
}
Some complete examples:
- Versioned examples:
- Unversioned examples:
Compilation features
- [default]
sled_engine, use sled as the backend database- Faster compilation speed
- Support for compiling into a statically linked binary
rocks_engine, use rocksdb as the backedn database- Faster running speed
- Can not be compiled into a statically linked binary
- [default]
cbor_ende, use cbor as theen/decoder- Faster running speed
bcs_ende, use bcs as theen/decoder- Created by the libre project of Facebook
- Security reinforcement for blockchain scenarios
Low-level design
Based on the underlying one-dimensional linear storage structure (native kv-database, such as sled/rocksdb, etc.), multiple different namespaces are divided, and then abstract each dimension in the multi-dimensional logical structure based on these divided namespaces.
In the category of kv-database, namespaces can be expressed as different key ranges, or different key prefix.
This is the same as expressing complex data structures in computer memory(the memory itself is just a one-dimensional linear structure).
User data will be divided into two dimensions: 'branch' and 'version', the functions of the 'basic' category are stateless, and the functions of the 'versioned' category are stateful. In the internal implementation, each stateful function is implemented based on its corresponding stateless function, all stateful data has two additional identification dimensions ('branch' and 'version'), somewhat like the logic in Git. Stateless functions do not have the feature of 'version' management, but they have higher performance.
1 Jan 28, 2022
5 Sep 26, 2022
204 Jan 6, 2023
16 Nov 30, 2022
14 Nov 14, 2021
13 Jan 4, 2023
602 Dec 29, 2022
27 Oct 29, 2022
292 Nov 4, 2022
10 Mar 28, 2023
3 Apr 30, 2023
4 Aug 24, 2023
6 Feb 29, 2024
5 Apr 26, 2022
101 Nov 12, 2022
11.8k Jan 5, 2023
214 Dec 26, 2022
1.9k Jan 8, 2023
776 Dec 30, 2022
4 Aug 24, 2023
10 Jul 15, 2022
14 Aug 16, 2022
14 May 30, 2023
3 Jul 27, 2023
306 Jul 12, 2023
3 Nov 20, 2023
38 Jan 2, 2024
4 Aug 14, 2022
5k Jan 9, 2023