Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Design Review: Key-Value Storage

mozilla.github.io

Post reply on HN
Print view View original

1–10 of 90 posts

Re: Design Review: Key-Value Storage

#3

Post by wvenable »

amelius wrote: post #2

Seems like an instance of reinventing the wheel ...

From the article:

"We propose ‘buying’, not building, the core of such a solution, and wrapping it in idiomatic libraries that we can use on all platforms.

We propose that LMDB is a suitable core (see Appendix A for options considered): it is compact (32KB of object code), well-tested, professionally maintained, reliable, portable, scales well, and is exceptionally fast for our kinds of load. We have engineers at Mozilla with prior experience with LMDB, and their feedback is entirely positive."

Re: Design Review: Key-Value Storage

#7

Post by coleifer »

lclarkmichalek wrote: post #6

I'm really surprised LSM trees didn't get more commentary. 'All are targeted at server workloads' - sure, but they're also incredibly popular and appear to be as close to the 'one-size-fits-all solution for storage' as we've found.

Also typically more complicated and require a separate compaction process. They're good for writing lots of data, but not so great for random reads.

Re: Design Review: Key-Value Storage

#8

Post by jcranmer »

smacktoward wrote: post #5

Bring back Mork! ducks

Mork actually sucked even as a key-value store. It's only decent if your requirements are a) only lookup on a fixed, autoincrement integer ID, b) the only operation you're likely to do is load an entire record or store an entire record at once, and c) parallelism is not in your vocabulary.

Disclaimer: I'm one of the last people to make functional changes to mork.

Post reply on HN