|
| 1 | +# Key/Value Encoding |
| 2 | + |
| 3 | +The key/value store uses binary `Vec<u8>` keys and values, so we need an encoding scheme to |
| 4 | +translate between Rust in-memory data structures and the on-disk binary data. This is provided by |
| 5 | +the [`encoding`](https://github.com/erikgrinaker/toydb/tree/213e5c02b09f1a3cac6a8bbd0a81773462f367f5/src/encoding) |
| 6 | +module, with separate schemes for key and value encoding. |
| 7 | + |
| 8 | +## `Bincode` Value Encoding |
| 9 | + |
| 10 | +Values are encoded using [Bincode](https://github.com/bincode-org/bincode), a third-party binary |
| 11 | +encoding scheme for Rust. Bincode is convenient because it can easily encode any arbitrary Rust |
| 12 | +data type. But we could also have chosen e.g. [JSON](https://en.wikipedia.org/wiki/JSON), |
| 13 | +[Protobuf](https://protobuf.dev), [MessagePack](https://msgpack.org/), or any other encoding. |
| 14 | + |
| 15 | +We won't dwell on the actual binary format here, see the [Bincode specification](https://github.com/bincode-org/bincode/blob/trunk/docs/spec.md) |
| 16 | +for details. |
| 17 | + |
| 18 | +To use a consistent configuration for all encoding and decoding, we provide helper functions using |
| 19 | +`bincode::config::standard()` in the [`encoding::bincode`](https://github.com/erikgrinaker/toydb/blob/213e5c02b09f1a3cac6a8bbd0a81773462f367f5/src/encoding/bincode.rs) |
| 20 | +module: |
| 21 | + |
| 22 | +https://github.com/erikgrinaker/toydb/blob/0ce1fb34349fda043cb9905135f103bceb4395b4/src/encoding/bincode.rs#L15-L27 |
| 23 | + |
| 24 | +Bincode uses the very common [Serde](https://serde.rs) framework for its API. toyDB also provides |
| 25 | +an `encoding::Value` helper trait for value types with automatic `encode()` and `decode()` methods: |
| 26 | + |
| 27 | +https://github.com/erikgrinaker/toydb/blob/b57ae6502e93ea06df00d94946a7304b7d60b977/src/encoding/mod.rs#L39-L68 |
| 28 | + |
| 29 | +Here's an example of how this is used to encode and decode an arbitrary `Dog` data type: |
| 30 | + |
| 31 | +```rust |
| 32 | +#[derive(serde::Serialize, serde::Deserialize)] |
| 33 | +struct Dog { |
| 34 | + name: String, |
| 35 | + age: u8, |
| 36 | + good_boy: bool, |
| 37 | +} |
| 38 | + |
| 39 | +impl encoding::Value for Dog {} |
| 40 | + |
| 41 | +let pluto = Dog { name: "Pluto".into(), age: 4, good_boy: true }; |
| 42 | +let bytes = pluto.encode(); |
| 43 | +println!("{bytes:02x?}"); |
| 44 | + |
| 45 | +// Outputs [05, 50, 6c, 75, 74, 6f, 04, 01]. |
| 46 | +// |
| 47 | +// * Length of string "Pluto": 05. |
| 48 | +// * String "Pluto": 50 6c 75 74 6f. |
| 49 | +// * Age 4: 04. |
| 50 | +// * Good boy: 01 (true). |
| 51 | + |
| 52 | +let pluto = Dog::decode(&bytes)?; // gives us back Pluto |
| 53 | +``` |
| 54 | + |
| 55 | +## `Keycode` Key Encoding |
| 56 | + |
| 57 | +Unlike values, keys can't just use any binary encoding like Bincode. As mentioned before, the |
| 58 | +storage engine sorts data by key to enable range scans, which will be used e.g. for SQL table scans, |
| 59 | +limited SQL index scans, Raft log scans, etc. Because of this, the encoding needs to preserve the |
| 60 | +[lexicographical order](https://en.wikipedia.org/wiki/Lexicographic_order) of the encoded values: |
| 61 | +the binary byte slices must sort in the same order as the original values. |
| 62 | + |
| 63 | +As an example of why we can't just use Bincode, let's consider two strings: "house" should be |
| 64 | +sorted before "key", alphabetically. However, Bincode encodes strings prefixed by their length, so |
| 65 | +"key" would be sorted before "house" in binary form: |
| 66 | + |
| 67 | +``` |
| 68 | +03 6b 65 79 ← 3 bytes: key |
| 69 | +05 68 6f 75 73 65 ← 5 bytes: house |
| 70 | +``` |
| 71 | + |
| 72 | +For similar reasons, we can't just encode numbers in their native binary form, because the |
| 73 | +[little-endian](https://en.wikipedia.org/wiki/Endianness) representation will sometimes order very |
| 74 | +large numbers before small numbers, and the [sign bit](https://en.wikipedia.org/wiki/Sign_bit) |
| 75 | +will order positive numbers before negative numbers. |
| 76 | + |
| 77 | +We also have to be careful with value sequences, which should be ordered element-wise. For example, |
| 78 | +the pair ("a", "xyz") should be ordered before ("ab", "cd"), so we can't just encode the strings |
| 79 | +one after the other like "axyz" and "abcd" since that would sort "abcd" first. |
| 80 | + |
| 81 | +toyDB provides an encoding called "Keycode" which provides these properties, in the |
| 82 | +[`encoding::keycode`](https://github.com/erikgrinaker/toydb/blob/213e5c02b09f1a3cac6a8bbd0a81773462f367f5/src/encoding/keycode.rs) |
| 83 | +module. It is implemented as a [Serde](https://serde.rs) (de)serializer, which |
| 84 | +requires a lot of boilerplate code, but we'll just focus on the actual encoding. |
| 85 | + |
| 86 | +Keycode only supports a handful of primary data types, and just needs to order values of the same |
| 87 | +type: |
| 88 | + |
| 89 | +* `bool`: `00` for `false` and `01` for `true`. |
| 90 | + |
| 91 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L113-L117 |
| 92 | + |
| 93 | +* `u64`: the [big-endian](https://en.wikipedia.org/wiki/Endianness) binary encoding. |
| 94 | + |
| 95 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L157-L161 |
| 96 | + |
| 97 | +* `i64`: the [big-endian](https://en.wikipedia.org/wiki/Endianness) binary encoding, but with the |
| 98 | + sign bit flipped to order negative numbers before positive ones. |
| 99 | + |
| 100 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L131-L143 |
| 101 | + |
| 102 | +* `f64`: the [big-endian IEEE 754](https://en.wikipedia.org/wiki/Double-precision_floating-point_format) |
| 103 | + binary encoding, but with the sign bit flipped, and all bits flipped for negative numbers, to |
| 104 | + order negative numbers correctly. |
| 105 | + |
| 106 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L167-L179 |
| 107 | + |
| 108 | +* `Vec<u8>`: terminated by `00 00`, with `00` escaped as `00 ff` to disambiguate it. |
| 109 | + |
| 110 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L190-L205 |
| 111 | + |
| 112 | +* `String`: like `Vec<u8>`. |
| 113 | + |
| 114 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L185-L188 |
| 115 | + |
| 116 | +* `Vec<T>`, `[T]`, `(T,)`: just the concatenation of the inner values. |
| 117 | + |
| 118 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L295-L307 |
| 119 | + |
| 120 | +* `enum`: the enum variant's numerical index as a `u8`, then the inner values (if any). |
| 121 | + |
| 122 | + https://github.com/erikgrinaker/toydb/blob/2027641004989355c2162bbd9eeefcc991d6b29b/src/encoding/keycode.rs#L223-L227 |
| 123 | + |
| 124 | +Decoding is just the inverse of the encoding. |
| 125 | + |
| 126 | +Like `encoding::Value`, there is also an `encoding::Key` helper trait: |
| 127 | + |
| 128 | +https://github.com/erikgrinaker/toydb/blob/b57ae6502e93ea06df00d94946a7304b7d60b977/src/encoding/mod.rs#L20-L37 |
| 129 | + |
| 130 | +We typically use enums to represent different kinds of keys. For example, if we wanted to store |
| 131 | +cars and video games, we could use: |
| 132 | + |
| 133 | +```rust |
| 134 | +#[derive(serde::Serialize, serde::Deserialize)] |
| 135 | +enum Key { |
| 136 | + Car(String, String, u64), // make, model, year |
| 137 | + Game(String, u64, Platform), // name, year, platform |
| 138 | +} |
| 139 | + |
| 140 | +#[derive(serde::Serialize, serde::Deserialize)] |
| 141 | +enum Platform { |
| 142 | + PC, |
| 143 | + PS5, |
| 144 | + Switch, |
| 145 | + Xbox, |
| 146 | +} |
| 147 | + |
| 148 | +impl encoding::Key for Key {} |
| 149 | + |
| 150 | +let returnal = Key::Game("Returnal".into(), 2021, Platform::PS5); |
| 151 | +let bytes = returnal.encode(); |
| 152 | +println!("{bytes:02x?}"); |
| 153 | + |
| 154 | +// Outputs [01, 52, 65, 74, 75, 72, 6e, 61, 6c, 00, 00, 00, 00, 00, 00, 00, 00, 07, e5, 01]. |
| 155 | +// |
| 156 | +// * Key::Game: 01 |
| 157 | +// * Returnal: 52 65 74 75 72 6e 61 6c 00 00 |
| 158 | +// * 2021: 00 00 00 00 00 00 07 e5 |
| 159 | +// * Platform::PS5: 01 |
| 160 | + |
| 161 | +let returnal = Key::decode(&bytes)?; |
| 162 | +``` |
| 163 | + |
| 164 | +Because the keys are sorted in element-wise order, this would allow us to e.g. perform a prefix |
| 165 | +scan to fetch all platforms which Returnal (2021) was released on, or perform a range scan to fetch |
| 166 | +all models of Nissan Altima released between 2010 and 2015. |
| 167 | + |
| 168 | +--- |
| 169 | + |
| 170 | +<p align="center"> |
| 171 | +← <a href="storage.md">Storage Engine</a> | <a href="mvcc.md">MVCC Transactions</a> → |
| 172 | +</p> |
0 commit comments