1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59

//! #### what is sled?
//!
//! * an embedded kv store
//! * a construction kit for stateful systems
//! * ordered map API similar to a Rust `BTreeMap<Vec<u8>, Vec<u8>>`
//! * fully atomic single-key operations, supports CAS
//! * zero-copy reads
//! * merge operators
//! * forward and reverse iterators
//! * a monotonic ID generator capable of giving out 75-125+ million unique IDs
//!   per second, never double allocating even in the presence of crashes
//! * [zstd](https://github.com/facebook/zstd) compression (use the zstd build
//!   feature)
//! * cpu-scalable lock-free implementation
//! * SSD-optimized log-structured storage
//!
//! #### why another kv store?
//!
//! People face unnecessary hardship when working with existing embedded
//! databases. They tend to have sharp performance trade-offs, are difficult to
//! tune, have unclear consistency guarantees, and are generally inflexible.
//! Facebook uses distributed machine learning to find configurations that
//! achieve great performance for specific workloads on rocksdb.  Most engineers
//! don't have access to that kind of infrastructure. We would like to build
//! sled so that it can be optimized using simple local methods, with as little
//! user input as possible, and in many cases exceed the performance of popular
//! systems today.
//!
//! This is how we aim to improve the situation:
//!
//! 1. don't make the user think. the interface should be obvious.
//! 1. don't surprise users with performance traps.
//! 1. don't wake up operators. bring reliability techniques from academia into
//! real-world practice. 1. don't use so much electricity. our data structures
//! should play to modern hardware's strengths.
//!
//! sled is written by people with experience designing, building, testing, and
//! operating databases at high scales. we think the situation can be improved.
//!
//! #### targeted toward our vision of the future
//! Building a database takes years. Designers of databases make bets about
//! target usage and hardware. Here are the trends that we see, which we want to
//! optimize the experience around:
//!
//! 1. more cores on servers, spanning sockets and numa domains
//! 1. the vast majority of content consumption and generation happening on
//! phones 1. compute migrating to the edge, into CDNs
//! 1. conflict-free and OT-based replication techniques at the edge
//! 1. strongly-consistent replication techniques within and between datacenters
//! 1. event-driven architectures which benefit heavily from subscriber/watch
//! semantics

pub mod engineering_practices;
pub mod limits;
pub mod merge_operators;
pub mod performance_guide;
pub mod reactive_semantics;
pub mod sled_architectural_outlook;
pub mod testing_strategies;