Live data from Hacker News

Faster – Fast key-value store from Microsoft Research

github.com

61–70 of 84 posts

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

#61

The VLDB reviewers of their paper [1] must not have thought much of it because it's accepted as a short paper, which is not a great signal. No comment on the quality of the work though, as I only just started reading it. [1] https://www.microsoft.com/en-us/research/uploads/prod/2018/0...

Interestingly, the hash bucket structure presented in their papers does not match the one on their code [0], but that probably means they've made some sort of improvement post-publications.

[0] https://github.com/Microsoft/FASTER/blob/master/cc/src/core/...

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

#62
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?

They sit under a service you would actually use. For instance, I think mysql can use rocksdb as a storage backend.

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

#63
post #8

Earlier quoted context omitted.

It'd be awesome if they provided a comparison of other tools on the same hardware like, "on an AWS M4.xlarge instance we were able to achieve 160m/ops/sec when the dataset fit into memory where as redis only did X" Lacking that I agree it's a pretty meaningless stat.

No benchmark means anything on an EC2 shared instance (or probably any other cloud instance) because you don't know what else is running on the machine.

What about running the benchmark multiple times on instances of the same type? I get that it would be noisy but lots of workloads run on shared instances so it’s a useful measuring stick in that way.

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

#64
post #39
post #34

Earlier quoted context omitted.

That's not why you don't run them on a shared host. It's because every other tenant on the machine is going to make run of the same benchmark unpredictable, and it will likely vary greatly through the day. Even taking multiple runs of each benchmark isn't sufficient, because you don't know the usage patterns of other tenants.

You're making it sound like performance on such hosts in unknowable which isn't really accurate. 'Multiple runs of each benchmark' is vague enough to be potentially insufficient in just about any environment to boot.

Variance matters though. Test where you can reasonably be sure about low variance.

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

#65
post #64
post #39

Earlier quoted context omitted.

You're making it sound like performance on such hosts in unknowable which isn't really accurate. 'Multiple runs of each benchmark' is vague enough to be potentially insufficient in just about any environment to boot.

Variance matters though. Test where you can reasonably be sure about low variance.

Sure. But it can be measured and accounted for. The idea that you can't or shouldn't benchmark such environments seems weird, given that they're pretty popular.

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

#66
post #65
post #64

Earlier quoted context omitted.

Variance matters though. Test where you can reasonably be sure about low variance.

Sure. But it can be measured and accounted for. The idea that you can't or shouldn't benchmark such environments seems weird, given that they're pretty popular.

[deleted]

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

#68
post #63

Earlier quoted context omitted.

No benchmark means anything on an EC2 shared instance (or probably any other cloud instance) because you don't know what else is running on the machine.

What about running the benchmark multiple times on instances of the same type? I get that it would be noisy but lots of workloads run on shared instances so it’s a useful measuring stick in that way.

[deleted]

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

#69

This is really interesting. This is usually what people would do when using NoSQL database to reduce latency by caching elements with an in-memory database. Basically they are mixing up Redis with RocksDB , which is what devs usually do to get even higher throughput by storing IDs in Redis to save a call to RocksDB. Now what bother me is the look of repository , it looks completely rushed out. No logo , unclear descr…

> Now what bother me is the look of repository , it looks completely rushed out.

> No logo , unclear description of the tech...

it's not a product, it's the code that accompanies a white paper.

https://www.microsoft.com/en-us/research/project/FASTER/

Post reply on HN