Slicer: Auto-Sharding for Datacenter Applications | Hacker News Reader

Slicer: Auto-Sharding for Datacenter Applications

usenix.org

58 pointsmlerner12 comments

From 2016. It's nice to have the option between the slides[0], 22m of audio[1] and whitepaper[2]

[0]: https://www.usenix.org/system/files/conference/osdi16/osdi16... [1]: https://2459d6dc103cb5933875-c0245c5c937c5dedcca3f1764ecc9b2... [2]: https://www.usenix.org/system/files/conference/osdi16/osdi16...

Slicer is mentioned briefly in the PWL talk on Zanzibar[0]. I've chatted with a few folks from Uber that worked on Ringpop[1], which was inspired by Slicer, but doesn't have any of the novel dynamic balancing properties. I still don't think there's anything anbalagous outside of Google.

[0]: https://youtu.be/1nbSbe3kw2U?t=1612

[1]: https://github.com/uber/ringpop-go

I worked on ringpop and the associated tech at Uber, though I wasn’t part of the original design & implementation. This isn’t the origin story I remember. My recollection is that ringpop was inspired by the SWIM paper, Hashicorp’s Serf, and Microsoft Orleans, and was part of an overall desire to move away from Chubby-like CP systems to AP designs.

Isn’t the sweet spot a combination of AP and CP for different parts of the same problem?

Arguably that’s what Slicer implements. It’s AP for high traffic routing requests that use it, and CP for slower decision making.

Same could be said for things like FoundationDB (and I’d guess Spanner) – topology in CP, “customer activity” in AP, resulting in a system that degrades very gracefully. A bit of a simplification, but I think it’s a good model for services like this.

From the people that I've spoken to, you are correct that this is where the implementation eventually arrived, but I'm not sure that was the original intent. I know at one point they tried a Go rewrite, but I'm not sure that ever shipped or if any design changes were made.

Super interesting.

The TL;DR is that google built a system to shard client requests into different services/task by some largish shard key. The example they provide is to shard requests into ML model services by the underlying language (English vs Chinese) as different languages need different models.

Rather than requiring each product team to manage sharding, google built a custom layer to do it for any team to use. In practice it's not used by that many teams (~20 services at Google use it).

* >20 when this was published in 2016.

Slicer is one of those things that enjoys a lot more currency outside Google than inside it, though.

It's pretty well-respected within the mothership Jeff..

Was gonna say, this is the most popular HN thread about slicer ever. I'll admit it has its shortcomings (as someone who built a tool that was theoretically almost perfect for slicer, but didn't quite fit it), and has some other limitations for potential large clients. But I think it gets more mindshare within Google than without (especially today).

Ok maybe it hasn’t taken HN by storm but at three large, public companies in my post-google experience they all had re-implemented slicer, but they all lacked other, simpler and more generally useful rpc directors that are much more common, but don’t have papers to go with them.

Does Slicer work with range partitions?

Reply on news.ycombinator.com