Faster – A key-value store for large state management

https://www.microsoft.com/en-us/research/blog/microsoft-unveils-faster-key-value-store-large-state-management/

by tim_sw • 8 years ago

142 34 8 years ago

microsoft.com

setquk4• 8 years ago

Does anyone remember MS Velocity / AppFabric Cache? No. Because it was crap and they canned it suddenly.

Really, if they are still supporting this in 3 years and it materialises into the promises I will take a look again.

I will never immediately adopt an MSFT platform component.

softwarefounder• 8 years ago

This is getting down-voted, but there's some truth here.

I didn't adopt .NET Core until v2, and happy I waited. Much stronger support from MSFT now, and a much more stable framework.

setquk4• 8 years ago

Exactly the other side of my point. Once it’s supoorted it’s good.

noir_lord2• 8 years ago

Insane performance on the most recent techempower benchmarks (usual proviso of all bencharks are meaningless etc etc.) they've caught Go with fasthttp already on one of them.

atombender• 8 years ago

This is a paper coming out of Microsoft Research. Not a product. Think of it more like Google's papers on Spanner, Andromeda, etc., except it's probably not in production use within Microsoft.

manigandham3• 8 years ago

This isn't a commercial product or framework, it's Microsoft Research. They create many cutting-edge projects and do implement them internally in their own datacenters and services but they don't have the Google-like history of open-source clones based on the papers.

Velocity is the codename for the caching component of AppFabric, and AppFabric has evolved into Service Fabric, which now runs most of Microsoft's vast cloud services and has been recently open-sourced: https://github.com/Microsoft/service-fabric

setquk4• 8 years ago

Now you see here lies the problem. No one knew that who was using appfabric. We just got crapped on with this blog post and got told to move on and take our self hosted stuff to azure which at the time was a ball ache:

https://blogs.msdn.microsoft.com/appfabric/2015/04/02/micros...

The result of this is, to use the words I used at the time “well fuck you then” after we were told that this was the veritable jesus’s sandals of a product and the future of service oriented architecture at MSFT.

Now there’s a 180 on that post since, which we never checked up on because how would we know when we buggered off to memcache and foot the bill for the whole WCF and WWF rewrite debacle after 3.5. Then grumpily headed towards AWS and it was comfortable there. And now it’s open source and stuff (which judging by lesser parts of the ecosystem like SCVMM stuff on Linux) is probably going to be an abandoned wreck.

As always the marketing and roadmappery is crazy, disparate and impossible to track. We have no idea what direction MSFT is heading in, who is calling the shots and what’s going to happen next.

Which is the point. The maturity curve for MSFT software is a narrow window between two and five years. We can’t afford to rewrite our platform on that cycle.

And thus everyone leaves for greener pastures full of snakes, elephants, penguins and Bezos.

Fair point on MSR however.

mandioca• 8 years ago

I wonder if this is a kinda of paper that is meant to be used under the hood of key/value in existing data bases vs a brand new data base?

Rapzid• 8 years ago

I think you are spot on; this is an MS Research Blog post and not a product announcement. The most interesting thing in the post IMHO is the link to the paper. The Tango paper is another good read.

ihsw2• 8 years ago

Yes, the article mentions that its siblings includes RocksDB. There are already outsized (north of 5TB) embedded databases geared towards high-IOPS storage (ie: NVMe) and this project serves to establish C#/.NET Core as a platform to build similarly-specced analytics products.

merinowool• 8 years ago

What a unfortunate name. Good luck finding information when you need help with it.

overcast2• 8 years ago

Microsoft Faster is the first result.

vxNsr3• 8 years ago

Right bec it's in the news, wait two weeks, also the next 30 results are unrelated.

Also try searching something more realistic "FASTER lookup," "FASTER keystore," etc

vxNsr3• 8 years ago

So true, I hate when google does this too, what's wrong with using original names?

Not that this coulda been helped, but I spent like 2 hours yesterday trying to find info on the -filter param in powershell took me a very long time to find anything useful, and I still don't have the official doc on it.

quiq• 8 years ago

Were you searching for things like "powershell -filter"? That would exclude every result containing "filter" [1]

[1] https://support.google.com/websearch/answer/2466433?hl=en

giancarlostoro• 8 years ago

Yeah. I imagine everyone will call it Microsoft FASTER or MS Faster in Google land.

jesseryoung• 8 years ago

I believe this is just a Microsoft Research project. Based on the wording of the article I suspect they'll be using it within Microsoft products.

pjmlp• 8 years ago

Cool, implemented in C#.

gigatexal• 8 years ago

I want to play with it. Waiting for them to put the source on github. Too soon? ;)

bmelton• 8 years ago

Considering Microsoft is (and has been for some time) one of Github's most prolific users, I'd say if it's going to be open sourced, we should expect it soon.

ovao2• 8 years ago

To support failure recovery, FASTER incorporates a recovery strategy that can bring the system back to a recent consistent state at low cost

I'm at least intrigued, but this part is slightly worrying. "Recent consistent state" is unfortunately not "last good state", which would make it a non-starter for certain use cases.

naasking• 8 years ago

"Recent consistent state" is unfortunately not "last good state", which would make it a non-starter for certain use cases.

Is the issue "recent" or "consistent"? "Consistent" seems like a good metric for "good", so perhaps "how recent" is a problem you foresee?

ovao2• 8 years ago

The issue is “recent”, yes. I’m curious about “how recent”.

ram_rar• 8 years ago

First, we use a 50 : 50 Zipf workload, and plot throughput vs.RocksDB in Fig. 10. As expected, Faster slows down with limited memory because of increased random reads from SSD, but quickly reaches in-memory performance levels once the entire dataset fits in memory.

I dont mean to offend the authors in anyways. But can someone from facebook rocksDb team reproduce their results on rocksDB ? I am curious as to , why throughput remains constant, even though memory is increased from 5 -> 40GB.

fetbaffe• 8 years ago

What happens when Faster deadlocks? It starves.

julienfr112• 8 years ago

github or it doesn't exist

Faster – A key-value store for large state management

Related Stories