Live data from Hacker News

An embedded database written in Rust

github.com

51–60 of 74 posts

Re: An embedded database written in Rust

#51
post #25

Other people have had trouble wringing competitive performance out of Bw-Trees despite heroic optimization efforts [0]. Why is this implementation going to beat other index structures with just a bit of tuning? [0] https://news.ycombinator.com/item?id=17041616

That paper is pretty good but it's comparing bw-tree with much simpler in memory data structures. I think bw-tress might work specially well for fast-disk storage.

Re: An embedded database written in Rust

#52
post #50

Earlier quoted context omitted.

Your parent didn't say that. Speaking about Rust in a thread about a Rust project seems to be very on-topic? (I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)

> Your parent didn't say that. Yes and it's more disturbing. It says "In Rust abstractions are free" when an algorithm was discussed. Rust having "free" abstractions does not change the performance characteristics of an algorithm: this is what the grand-parent was talking about.

Yes, I certainly agree with that distinction. If you'd have said that in the first place, I wouldn't have said anything :)

Re: An embedded database written in Rust

#53
post #25

Other people have had trouble wringing competitive performance out of Bw-Trees despite heroic optimization efforts [0]. Why is this implementation going to beat other index structures with just a bit of tuning? [0] https://news.ycombinator.com/item?id=17041616

It might not. But the critiques of bw trees in terms of performance that I've seen have not had compelling data in terms of things that matter outside of academia or benchmarking shootouts, like write or space amplification. The bw tree is a cheap thing to abandon after I implement a persistent ART and measure it though. The bwtree is only like 1k of rust on top of the modular pagecache, which is the real heart of th…

I am not familiar with bw-trees, but are you aware of this paper from this year’s SIGMOD?

https://db.cs.cmu.edu/papers/2018/mod342-wangA.pdf

Moving to ARTs (possibly combined with B+ trees) might be a smart choice after all.

Edit: sorry, I missed that grand-parent has cited the same paper already.

Re: An embedded database written in Rust

#54
post #50

Earlier quoted context omitted.

Your parent didn't say that. Speaking about Rust in a thread about a Rust project seems to be very on-topic? (I would also disagree with that statement, but in a different way: Rust enables zero-cost abstractions, but nothing inherently means they have to be. I can also make quite costly ones, and they'll compile.)

> Your parent didn't say that. Yes and it's more disturbing. It says "In Rust abstractions are free" when an algorithm was discussed. Rust having "free" abstractions does not change the performance characteristics of an algorithm: this is what the grand-parent was talking about.

What is results disturbing is that you are arguing just for the sake of arguing. "Algorithm" is a too wide term - everything is an algorithm, especially in programming. Talk was about abstractions, now you're trying to say it was about algorithms. We need "ignore" button here.

Re: An embedded database written in Rust

#55
post #25

Other people have had trouble wringing competitive performance out of Bw-Trees despite heroic optimization efforts [0]. Why is this implementation going to beat other index structures with just a bit of tuning? [0] https://news.ycombinator.com/item?id=17041616

That paper is pretty good but it's comparing bw-tree with much simpler in memory data structures. I think bw-tress might work specially well for fast-disk storage.

This was my interpretation as well. I'm going to compare a disk-backed bwtree with a disk-backed ART, both backed by the same pagecache, and maybe end up with an ART that scatters partial pages on disk, bwtree style. But I need to measure apples to apples on the metrics that matter for storage first. The pagecache is where most of the complexity is in my implementation, and it makes building different kinds of persistent structures on top of it pretty easy. docs.rs/pagecache

Re: An embedded database written in Rust

#56

Earlier quoted context omitted.

You can't cluster an embedded database, this comment makes not sense. Compare with SQLite, not with Orcale or Postgres.

Currently it's even more basic. The current usable parts are a pagecache following the llama approach, some great testing utility libraries, and an index (that you can use as a kv) that follows the bwtree approach. Later it will have structured access support, but it needs some more db components to get there. It is a construction kit as well as a kv.

So... SQLite FoundationDB?

Re: An embedded database written in Rust

#57
post #25

Other people have had trouble wringing competitive performance out of Bw-Trees despite heroic optimization efforts [0]. Why is this implementation going to beat other index structures with just a bit of tuning? [0] https://news.ycombinator.com/item?id=17041616

That paper is pretty good but it's comparing bw-tree with much simpler in memory data structures. I think bw-tress might work specially well for fast-disk storage.

>I think bw-tress might work specially well for fast-disk storage.

That's precisely the claim made in the original paper describing Bw-trees.

https://dl.acm.org/citation.cfm?id=2510649.2511251

Re: An embedded database written in Rust

#59

I see that MVCC is a planned feature. Why would you need MVCC for an embedded database? It seems like unnecessary overhead that conflicts with the performance goals.

It's not needed for the single-key atomic record store, which is the sled bwtree index that is the current highest level module. MVCC is implemented in most popular embedded DBs because it is an effective way to manage mixed workloads that seek to read snapshots of the entire database at a single point in time as well as not blocking writes as this happens. This functionality is desirable for transactions that suppor…

MVCC is a viable general purpose approach to deal with concurrency. It is the mother of all DAGs.
Post reply on HN