7 ms·
Sled: Embedded Database Written in Rust
- dang 7y agoA thread from 2018: https://news.ycombinator.com/item?id=17170733 https://news.ycombinator.com/item?id=17170733
- PudgePacket 7y agoThere was an awesome talk very recently about Sled at FOSDEM, highly recommend. https://fosdem.org/2020/schedule/event/rust_techniques_sled/ https://fosdem.org/2020/schedule/event/rust_techniques_sled/ Talk breif: sled and rio modern database engineering with io_uring sled is an embedded database that takes advantage of modern lock-free indexing and flash-friendly storage. rio is a pure-rust io_uring library unlocking the linux kernel's new asynchronous IO interface. This short talk will cover techniques that have been used to take advantage of modern hardware and kernels while optimizing for long term developer happiness in a complex, correctness-critical Rust codebase.
- dragonsh 7y agoGood to see some more activity in embedded data space. Earlier used BerkleyDB [1], msql [2] (from where MySQL was built), Postgres 4.2 [3] and now settled on SQLite for all our embedded database needs. When need performance at present just use SQLite in memory db. Will give Sled a try when it reaches 1.0.0 as at present SQLite serves our embedded requirements. [1] https://launchpad.net/berkeley-db https://launchpad.net/berkeley-db [2] https://hughes.com.au/products/msql/ https://hughes.com.au/products/msql/ [3] https://dsf.berkeley.edu/postgres.html https://dsf.berkeley.edu/postgres.html
- ComputerGuru 7y agoMake sure to check out lmdb if you haven’t. It’s not relational and has an extremely anemic API but it makes a great low-level building block. Sled is similar I’m that regard, very different from the others you have named.
- willvarfar 7y agoI've seen some startling performance claims about LMDB, but don't know anyone using it. Why isn't LMDB used as an engine for e.g. MySQL? Why, for example, did Facebook go with LevelDB in MyRocks instead of LMDB?
- jnwatson 7y agoMy company uses LMDB extensively. LevelDB is a LSM database. LSM is generally better for write workloads over BTree DBs like LMDB and sled. LMDB also has a single writer restriction.
- fanf2 7y agoBIND9 can use LMDB for storing the configuration of dynamically added zones. https://www.isc.org/blogs/bind-release-911/ https://www.isc.org/blogs/bind-release-911/
- the_duke 7y agoSled is not really a competitor to those. Sled is an alternative to other on-disk key/value databases like RocksDB and LMDB.
- stbtrax 7y agoWhat kinds of systems is this used in? I'm assuming it's not for embedded systems at the microcontroller level?
- nemothekid 7y agoNo this would be used in places where you would use SQLite or rocksdb
- spectramax 7y agoAre there databases for embedded applications, such as ARM microcontrollers?
- giancarlostoro 7y agoProbably SQLite if not just flat files
- shakna 7y agoPutting SQLite onto a controller that isn't running a full OS is actually a lot of work. [0] There isn't a working RTOS port out there, last I checked. [0] https://sqlite.org/custombuild.html https://sqlite.org/custombuild.html
- giancarlostoro 7y agoWell yeah, depends on the boards limitations.
- shakna 7y agoI've used ports of BerkleyDB several times for things down at that level. It isn't very powerful, but it's enough you can use it for most microcontroller needs.
- fulafel 7y agohttp://iondb.org/ http://iondb.org/ is one.
- Ericson2314 7y agoWhy no Tree<K,V>? It would be very nice to say up front one wants fixed-sized keys and values and get the benefits. This whole hurr drrr arbitrary data k v thing never made sense to me. Truly Unstructured data is meaningless--that's information theory for you---so why not leverage some types?
- timClicks 7y agoAn application could easily create their own Tree<K,V> with serde or binencode or something else. A key/value database doesn't really want to know about an application's types, because that complicates storage algorithms because sorting is now much more complex. In the same way, asm doesn't really have data types. All you have are bytes and addresses. A database needs to be able to use the encoding that it's given, rather than create another type system underneath it.
- Ericson2314 7y ago> A key/value database doesn't really want to know about an application's type Relational DBs have for decades. > Because that complicates storage algorithms because sorting is now much more complex Leveraging the types to build better indices is huge. Different data admits different total orders / partial order / lattices / other mathematical structure. If you generalize the math to infinitely large tables, this is not the difference between certain queries existing or not existing, it is the deference between queries existing or not existing. One might say limit of algorithmic complexity is realizability https://ncatlab.org/nlab/show/realizability https://ncatlab.org/nlab/show/realizability.
- krenoten 7y agoThe best solution is to use a 0-copy format like flatbuffers, google's zerocopy library, or serde's borrow attributes https://serde.rs/lifetimes.html#borrowing-data-in-a-derived-impl https://serde.rs/lifetimes.html#borrowing-data-in-a-derived-... You're totally right that data is meaningless without the ability to use it. This is something I've been thinking about a lot, because it involves a lot of trade-offs that definitely were not apparent to me before I started building this. Ultimately, I do want to make it easy to write a Tree<K, V> on top of sled, but if I were to do it myself it would significantly reduce performance and impose restrictions on users that don't feel appropriate to me. * Being a lock-free B+ tree, there are a ton of cool techniques we can use on bytes that would not apply to arbitrary K types. For instance, all keys stored in a tree node are prefix encoded by the node's low key. This allows very long keys with common prefixes to be very cheaply stored, which is useful for things like F1-like embedded tables. We also do key truncation, where when we do a node split, we chop off the bytes necessary to actually differentiate between one side and the other, which further reduces the size of the index. Prefix encoding and suffix truncation are the bread and butter of modern B+ tree implementations, and that would hurt a lot to walk away from. * All K and V types must then be serializable and deserializable. In rust we represent this with traits that come from specific external libraries. serde took up half of the sled compilation time when it was being used, so I don't want to pull that back in as a mandatory requirement for all users. I could have my own traits for this, and if I do anything like this, it will be the approach I take, and then external crates will implement serde-sled etc... but by depending on external crates, it makes for a very brittle API surface that requires all users to target the exact same version of that external trait. The core must be self-consistent and not export any external types that would cause sharp dependency issues. * I like the idea of caching values that are deserialized only once, to avoid repeated deserialization costs on hot items. Something like this may be implemented in sled, but I haven't figured out the best way to represent it without causing memory issues etc... And in the mean time I'm more tempted to just point people to the 3 solutions above that let them view their bytes as structured data without many deserialization costs.
- Ericson2314 7y agoI'd love to see someone go for a "exo-db" architecture, where the layers are broken out into distinct crates. Expressiveness making this possible should be a main benefit of Rust on par with safety. c.f. http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.435.6095&rep=rep1&type=pdf http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.435...
- jiggawatts 7y agoApparently if you're on Windows you don't deserve performance: #[cfg(windows)] const MAX_THREADS: usize = 16; #[cfg(not(windows))] const MAX_THREADS: usize = 128; From: https://github.com/spacejam/sled/blob/bf37bd120fbf62f78408e04970705ea57563acfa/src/threadpool.rs#L14-L18 https://github.com/spacejam/sled/blob/bf37bd120fbf62f78408e0...
- rapsey 7y agoWell threadripper tests showed windows does not scale that high.
- jiggawatts 7y agoIt does, but the client code needs NUMA support, which Rust does not currently have. It doesn't help that the default behaviour in Windows is just stupid: "By default, an application is constrained to a single group, which should provide ample processing capability for the typical application." This is the new "640KB should be enough for everybody", except now it is "64 threads should be enough". See: https://docs.microsoft.com/en-us/windows/win32/procthread/processor-groups https://docs.microsoft.com/en-us/windows/win32/procthread/pr... https://www.anandtech.com/show/15483/amd-threadripper-3990x-review/3 https://www.anandtech.com/show/15483/amd-threadripper-3990x-...
- tjoff 7y agoSounds like a really sensible default to me.
- hinkley 7y agoWhich surprises me, because formal object ownership and read/write access sound like exactly the sorts of things you’d like to have for a NUMA machine.
- hinkley 7y ago> 64 threads should be enough. It’s more that if you have a purely sequential workflow, you get access to less than 2% of the CPU on a 64 core machine. And even if you’re a bit parallel, Amdahl’s law smacks you pretty hard here.
- cft 7y agoNot sure if this this still relevant, but sled had a memory leak that precluded us from using it for an actual production project 3 months ago: https://github.com/panicfarm/sltest https://github.com/panicfarm/sltest
- shakna 7y agoThe reproducible bug is great, and I went looking to see if it might have been fixed, but I didn't find the same bug in the list. Did you let sled know about the bug? Can you point me in that direction?
- cft 7y agoYes, I wrote in sled's discord on Nov 14 and got this from the author: hey @panicfarm, thanks for the reproduction code! I think this is the same issue that kerugma ran into and mentioned a couple days ago. I'm curious if it still happens on sled master? I just did a huge refactor and sometimes a bunch of issues just shake out. Anyway, I will turn this into a proper regression test and get the page_out method of PageCache to properly be called, which is the underlying root.
- krenoten 7y agoOn sled 0.31 the memory growth does not run away as with the earlier version. Note that some in-memory metadata tracking does accrue as nodes split and sled tracks where to find them in the future when the actual data is paged in. But this is still a fraction of data stored. The important thing is that sled is not stable yet. Don't bet your business on databases less than 5 years old. Sled doesn't turn 5 for a few more months, and I'm ironing out a few issues still that relate to production readiness. For now, treat it as a cache, as a responsible SRE would treat any database younger than 5 years old.
- kstenerud 7y ago> If you want to store numerical keys in a way that will play nicely with sled's iterators and ordered operations, please remember to store your numerical items in big-endian form. Little endian (the default of many things) will often appear to be doing the right thing until you start working with more than 256 items (more than 1 byte), causing lexicographic ordering of the serialized bytes to diverge from the lexicographic ordering of their deserialized numerical form. While I can understand that big endian ordering is convenient for size-indifferent lexical ordering, is the tradeoff worth it? Yes, your benchmarks will look better, but real-world usage will require clients to continually byte swap. So you've basically forced a performance drop into user code. Also, wouldn't size-aware compares perform better in the generated machine code anyway?
- rapsey 7y agoTurning around 8 bytes is a miniscule cost compared to the cost of having a badly formed index. There really is no way around data not being big endian.
- krenoten 7y agoyeah, le-be conversions are not generally measurable above noise compared to other database-related work. sled stores arbitrary bytes. endianness is the concern of the person who wants to store higher-level types than bytes, like integers. I do imagine having a story for letting people deserialize/view bytes once, and having that view sit in cache so that hot items are not repeatedly deserialized. I agree with Adya's work " Fast key-value stores: An idea whose time has come and gone " https://research.google/pubs/pub48030/ https://research.google/pubs/pub48030/ where it makes the case that stateful systems should not have to pay repeated deserialization and network costs. I want sled to be well-situated for the world that we're headed into, where this view will become more prominent. This means caching deserialized data, better replication stories, and maybe nice helpers for distributed database authors that allow for atomic tree splits / merges and per-tree replication settings.