Live data from Hacker News

Faster – Fast key-value store from Microsoft Research

github.com

81–84 of 84 posts

Re: Faster – Fast key-value store from Microsoft Research

#81

Why the hell is Microsoft so bad at naming?! I'm sure it will be easy to find information about this, .NET, abysmally performing FAST search product (which is named too close to this with too much overlap), Creators update, SQL Server like they're the only SQL capable server out there even though it's based on somebody else's product etc...

Google is worse. The “Play Store,” which should be only games.

Google Video... we all know how that turned out.

Google Plus: Not only a worthless, idiotic name; but Google actually crippled its core product (search) by removing “+” as the “requires” operator for search terms... apparently because it “interfered” Google Plus.

Then there’s the mess that is Android.

Re: Faster – Fast key-value store from Microsoft Research

#82
post #56

I have seen plenty of local-machine fast key-value stores, such as LevelDB (By Google), or RocksDB (By Facebook), but I have a hard time imagining what they are for. What are the use cases for such a library?

Imagine you want to run a service. This service needs to maintain some intermediate state. This state might’ve frequently read. There might be little value in persisting this state. Also, your service is used by many users, so this state can grow to be pretty big. For example, contents of a shopping cart. One solution is to maintain such state in some key-value store. Different functions of your service can query thi…

sooo.... what's the difference with your run-of-the-mill hash map / ordered map / whatever ? How does it compare to other maps such as these ones ? https://tessil.github.io/2016/08/29/benchmark-hopscotch-map....

Re: Faster – Fast key-value store from Microsoft Research

#84

Earlier quoted context omitted.

Imagine you want to run a service. This service needs to maintain some intermediate state. This state might’ve frequently read. There might be little value in persisting this state. Also, your service is used by many users, so this state can grow to be pretty big. For example, contents of a shopping cart. One solution is to maintain such state in some key-value store. Different functions of your service can query thi…

I think it's an in-memory embedded library, so why not just use a global variable map/dictionary?

> so this state might grow pretty big

As mentioned by the comment you replied to, it's because FASTER (and similar libraries) allow persisting this to disk in an efficient manner. If it can fit in memory and your language/framework has an efficient hashmap implementation, then you're right.. it's probably not worth using something like this.

Post reply on HN