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

Faster – Fast key-value store from Microsoft Research

github.com

Post reply on HN
Print view View original

21–30 of 84 posts

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

#21

Post by makmanalp »

fein wrote: post #6

It would be nice to know why I would use this instead of something tried and tested like Redis, but the sparse description doesn't really help.

You wouldn't - first and foremost, this is probably most useful as a storage layer for some more higher-level data store.

Second, think of software artifacts from papers as a proof of concept, or a prototype. It's intended more to demonstrate some architectural innovation, and less to serve customer needs. Their ideas revolve around supporting a high level of concurrent access and removing the locking overhead that would normally stem from this, and an interesting way to handle spilling over to disk in larger-than-memory scenarios. This might evolve into a customer-oriented product eventually. Or perhaps get retrofitted into the guts of something like MS SQL server.

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

#22

Post by makmanalp »

fizx wrote: post #15

If you want concrete benchmarks, they compare to RocksDB and Redis around page 10 of their academic paper. ( https://www.microsoft.com/en-us/research/uploads/prod/2018/0... ) TL;DR: I find their choice of benchmarks to be very convenient. They tested on in-memory 8 byte payloads and were way faster than RocksDB and Redis. They then tested against only different configurations of themselves for configurations that hit…

> They then tested against only different configurations of themselves for configurations that hit disk.

In the case of Redis, AFAIK it can't support larger than memory use cases, right? And in fact they do compare to RocksDB for larger-than-memory, see Fig 10. Granted, it could be more detailed, but I think it makes their point.

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

#23

Post by faragon »

"up to 160 million operations per second"

Read operations? Write operations? Per core, or using N cores?

For the case of one core at 3GHz, it would mean 20 CPU cycles per operation, which is barely enough for storing the data in the RAM for a log write. If using more than one core, e.g. one for writing the log, and others for updating the actual data structures, could imply much longer times for completing one operation, despite doing 160M per second on average: in that case it would not their "faster" would mean scalable rather than faster.

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

#24

Post by ddorian43 »

haney wrote: post #8
mooman219 wrote: post #3

"What differentiates FASTER are its cache-optimized index that achieves very high performance — up to 160 million operations per second when data fits in memory;" I really dislike when papers make performance claims like this in the introduction. That "160 million" number is so meaningless at face value because everything from the runtime environment to the hardware is going to play a huge role in ops. I rather see h…

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.

Don't do benchmarks on shared-host.

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

#26

Post by skyde »

I had to opportunity to look at the code. I believe this should be compared against embedded hash database such as "kyoto cabinet, LevelDB, RocksDB" . They introduce a novel latch free hashtable that they say is faster than other in memory data structure.

They also introduce a new disk persistence system called HybridLog that combines in-place updates (in memory) and log-structured organization (on disk).

The interesting aspect of the HybridLog is that it act as a bufferpool but seem to work at the record level instead of working with pages like a B-tree buffer pool would or compressed block as levelDB block_cache does.

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

#27

Post by dormando »

nolok wrote: post #4
mooman219 wrote: post #3

"What differentiates FASTER are its cache-optimized index that achieves very high performance — up to 160 million operations per second when data fits in memory;" I really dislike when papers make performance claims like this in the introduction. That "160 million" number is so meaningless at face value because everything from the runtime environment to the hardware is going to play a huge role in ops. I rather see h…

Agreed. Hardware and software has had a fair amount of upgrades since then, but reading that I could pseudo-remember that quote by the memcache guy that goes something like "you can't tell if that or that tweak is giving you a few % more requests because you're being i/o limited by your network link anyway".

close enough.

heavily batched on a 48 core I can pull 50 million keys/sec over localhost. if you remove syscalls and use it as a library it should double at least.

writes are another story, but they're slower because nobody asks for them to be faster.

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

#28

Post by jamesblonde »

kodablah wrote: post #12
mooman219 wrote: post #3

"What differentiates FASTER are its cache-optimized index that achieves very high performance — up to 160 million operations per second when data fits in memory;" I really dislike when papers make performance claims like this in the introduction. That "160 million" number is so meaningless at face value because everything from the runtime environment to the hardware is going to play a huge role in ops. I rather see h…

And: "FASTER achieves higher throughput than current systems, by more than two orders of magnitude, and scales better than current pure in-memory data structures, for in-memory working sets." Looking at 7.2 of the paper, they probably mean "more than 2x", definitely not exponentially faster in most cases. Still nice work though.

Two orders of magnitude is patently not true. MySQL Cluster has been benched at 200m ops/s (where operations are part of 2PC transactions!). And that in 2015! https://www.mysql.com/why-mysql/benchmarks/mysql-cluster/

The echo chamber of silicon valley is an important reason why MySQL Cluster is not more popular.

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

#30

Post by ebikelaw »

ddorian43 wrote: post #24
haney wrote: 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.

Don't do benchmarks on shared-host.

If that’s your production environment then that’s where you should run them.
Post reply on HN