Birbla

Join the discussion

Write your take first — we'll ask for email only when you're ready to publish.

Sign in
  • Hacker News
  • Is an atomic get+delete operation planned?
    by Tepix
  • It’s usually very difficult in a KV db to have an efficient operation that returns the item deleted. You’d need a transaction API to do it reliably. The challenge is concurrent writes are impossible to serialize against without transactions.

    This DB doesn’t have a transaction API.

    by vlovich123
  • Fast compared to what?
    by Surac
  • Now that “blazing fast in Rust” has become a meme, is “insanely” the next thing?
    by rollulus
  • Insanely/ridiculously.
    by carlos-menezes
  • Aphyr or gtfo
    by AtlasBarfed
  • Editorialized? Where does the repo claim to be "Insanely fast"? Has there been a change to the Readme since submission?

    If not, please just link the repo and its own title, no need for hype.

    by mellosouls
  • How does it compare to RocksDB?
    by dist-epoch
  • I like the fact that the first commits were about the logo, important things first :D
    by mattrighetti
  • Embedded could also mean no_std, which this is absolutely not. Still cool though
    by boguscoder
  • Yep, the correct term here is "embeddable", not embedded.
    by LoganDark
  • Every programmer eventually creates own db: https://github.com/antonmedv/medb
    by medv
  • A file-backed hashtable isn't really a DB.
    by otabdeveloper4
  • No way(hides)
    by idontneedcoffee
  • Yep. I made a simple one in Bash even! (Do not recommend.)
    by nunez
  • And it's not complete until it can send and receive email.
    by timschmidt
  • Building dbs is lots of fun. I recently did a few. Some in rust and some in go. And its really interesting.
    by yawniek
  • Most of these "insanely fast" projects kind of feel like people rediscovering compiled languages after the scripting languages dark ages.

    Insanely fast was making 8 bit games possible at all.

    by pjmlp
  • More or less. I think the use of CPU specific instructions can make an compiled program different than "the rest". Although nowadays some compilers are clever enough to do better than manual optimization.
    by xtracto
  • The benchmark is setup to test 80 MiB dataset on a machine with 32 GiB RAM, which doesn't represent a typical database workload. How does the key-value store perform on larger than RAM datasets? MMAP is fast when the dataset fits in memory, but it can slow to a crawl when it doesn't, especially if the workload is mostly random point lookups.
    by KAdot
  • > DbOptions::durable()

    > Appended to the WAL without a per-write sync

    So… it’s not durable? Durable doesn’t mean “survives a process restart”, it means “durably saved to persistent storage”. For example, this “durable” mode wouldn’t survive power loss.

    by dangoodmanUT
  • Every few years someone pulls this. If you search HN for fsync you can see the trail :)
    by random3
  • 10 years after MongoDB is back....

    https://youtu.be/b2F-DItXtZs

    by Betelbuddy
  • Is fsync needed for every write in all projects? I am willing to trade database speed for the loss of the last written data within a 1-10ms window once or twice a year for non-financial and other non-critical data. So, power loss shouldn't be such a frequent event when there are active transactions at that moment, right?
    by railka
  • Are we back to MongoDB -- no fsync() but webscale speed?
    by deepsun
  • Absolutely. If they just dirty some pages in memory and return back to the client the benchmarks will look "insanely fast".

    I have nothing against this being a non-default option in a db/kv engine but anything advertising to be durable and not fsyncing by default is something I would stay away from. To me it's like a litmus test of how well the author knows/cares data durability and not destroying users data.

    by rdtsc
  • I give a little leeway to distributed systems that replicate and don't flush since there's a bit of middle ground assuming they're in different fault domains. Garage object storage defaults to that

    However, this doesn't appear to be the case here...

    Unsurprisingly, performance goes to crap when sync is enabled.

    This is pretty old now but has some useful fsync/sec numbers which can be completely divorced from other I/O performance https://www.percona.com/blog/fsync-performance-storage-devic...

    by nijave
  • Yeah this should be benchmarked against other systems that have flush() disabled.

    mmap is nice but it doesn’t support durable semantics in the way that we usually mean with databases.

    if a write is acknowledged it should not be forgotten, which is not what this is.

    by stingraycharles
  • Pretty much... paranoid() seems to be the real durable() which isn't a great look for a database project.

    Being able to recover a db without corruption beyound losing the last few writes is a pretty useful feature, and buys a lot of performance, but it would be better to label that clearly, as a reasonable expectation on the durable() preset would be for it to be Durable.

    by procaryote