For key value stores that make performance claims, it would be helpful if they would publish the time and space complexity graphs for various sample data workloads. Write/read, and various data homogeneity for at least one of the standard architectures in different kinds of memory and disk configurations if what is being touted is the novel storage architecture. And provide the scripts to generate said sample datasets.
Faster – Fast key-value store from Microsoft Research
41–50 of 84 posts
Re: Faster – Fast key-value store from Microsoft Research
#42Why 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...
Re: Faster – Fast key-value store from Microsoft Research
#43What does FASTER stand for? Because otherwise it's a terrible name, imo.
Yeah, it seems like an acronym, maybe some internal codename. But for some reason they didn't make it public.. Inappropriate? So... Fuck Anything Slower Than Expected Results? ;)
Re: Faster – Fast key-value store from Microsoft Research
#44What does FASTER stand for? Because otherwise it's a terrible name, imo.
Microsoft tends to choose bad names: See Visual Studio Code, the most ungooglable name ever.
Re: Faster – Fast key-value store from Microsoft Research
#45"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.
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.
Re: Faster – Fast key-value store from Microsoft Research
#46Re: Faster – Fast key-value store from Microsoft Research
#47For those wondering what this is, it is not a client/server app, from what I can tell, but an embedded engine. It looks like it's intended to be a library, and it's been implemented in two languages (C# and C++). To get something like Redis or Riak you would have to build API, clustering, etc. on top of it. So it's more analogous to libraries like RocksDB, BoltDB, BDB etc. Paper: https://www.microsoft.com/en-us/resea…
c++ part is one liner intrinsic which may be supported directly with new .net and several io methods which would be heavy on pinvoke calls like 5 per method if in c#, but these are very simple. so c++ part could be done in c and easily ported to unix. i guess c# should allow for pinvoke strategy like in lua to replace c++ more.
What kind of different strategies did you have in mind? So far as I know, P/Invoke already tries to be as low overhead as possible - e.g. primitive types and blittable structs are just passed as is, with no conversions. The recently added Span is also special-cased for P/Invoke.
Re: Faster – Fast key-value store from Microsoft Research
#48Re: Faster – Fast key-value store from Microsoft Research
#49The 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...
Re: Faster – Fast key-value store from Microsoft Research
#50Haven't read the papers yet, but it immediately reminds me of Anna: https://databeta.wordpress.com/2018/03/09/anna-kvs/
That link has comments between anna and faster authors. The best part being:
> There are two high-level design goals that separate Anna and FASTER.
> First of all, for Anna, we set out to explore an execution model that’s truly coordination-free; each thread accepts requests, performs computation and sends out response without communicating or waiting for other threads. We believe having a coordination-free execution model is the key to fully exploiting multi-core parallelism within a single machine, and scale out smoothly to a distributed setting. We acknowledge that the fundamental caveat of having a coordination-free execution model is that strong consistencies (linearizability, serializability) are not achievable. Anna instead offers a wide-spectrum of coordination-free consistencies taxonomized in Bailis’s HAT paper (http://www.vldb.org/pvldb/vol7/p181-bailis.pdf).
> In addition, in Anna we focus on exploring a unified architecture that works at any scale, from a single multi-core machine to NUMA to a geo-distributed setting. Under this goal, architectures that rely on shared memory within a machine (including FASTER) need to be redesigned as we move to a distributed setting. This complicates the software, and can introduce challenges in maintaining consistency as the execution model within nodes and across nodes are now different.
> Anna currently focuses on workloads that fit in memory. For larger-than-memory data, we believe Anna can benefit from the hybrid-logging technique in FASTER for efficiently persisting data to stable storage.