TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

Slog: Cheating the low-latency vs. strict serializability tradeoff

62 pointsby evanweaverover 5 years ago

4 comments

taldoover 5 years ago
How is Slog different (or better) than multiple asynchronously-replicated regional deployments of Spanner? Or, even simpler, a single Spanner deployment where different sets of groups have different replication configurations. That is, in fact, a fairly common deployment of Spanner internally at Google, with different sets of voting replicas for data that's most frequently accessed from different places. As an example: Paxos groups that host European users' data have a quorum of voting replicas in the EU, while groups that host US users' data have a quorum of voting replicas in the US. Data can be explicitly moved across these different sets of groups, e.g., in response to a user changing the location of their accesses. All the normal location resolution methods still work as in the simple case of uniform replication configurations (see Directories and Placement section in the original OSDI 2012 paper).
评论 #21184126 未加载
评论 #21183934 未加载
jumpingmiceover 5 years ago
"Cheating" is doing all of the work here. They are sending transactions to their "home location" which is worst case all the way on the other side of the planet and then they are only counting the time to apply the transaction at that location, instead of including the latency between the client and the homed frontend. So it's low latency if you draw the system boundaries in such a way but from the perspective of the client it's still high latency.
评论 #21183870 未加载
评论 #21183737 未加载
kcolfordover 5 years ago
It feels like they've snuck in an element of deterministic databases. This would explain why they don't take the penalty of the 2-phase commit round-trips. What's more interesting is how they've implemented this by just waiting for sufficient replica updates to appear in the database until they're confident in being strictly serializable. Of course, if those updates don't make it because of a network partition then the transaction will hang until it's over. Hopefully they really can count on there never being a network partition. Then again, a network partition would halt all related multi-homed transactions anyway so I guess it's a moot point.
评论 #21185218 未加载
karmakazeover 5 years ago
CockroachDB has a different cheat where the voting nodes would "follow the sun" as different regions would be the most highly active at different times of a 24h period. This has then been generalized to "follow the work" where each voting range keeps its voting nodes near the location of high activity. I'd like to see how this benchmarks to Slog.
评论 #21192169 未加载