3 ms·

How is Slog different (or better) than multiple asynchronously-replicated regional deployments of Spanner? Or, even simpler, a single Spanner deployment where d

by taldo 7y 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).

abadid 7y ago
Let's say you have a transaction that writes data located in different quorums atomically. This is called a "multi-home" transaction in SLOG. Most of the machinery in the paper is dealing with that case. SLOG can do that with half-round trip latency. No idea how long it would take the version of Spanner you described to do that, but presumably at least two full round trips across quorums for two-phase commit.
teraflop 7y ago
The paper [1] compares Slog against Spanner, both in theoretical terms and using benchmarks. If I'm understanding the paper correctly, I think it makes sense why Slog is better -- or at least, can do better in theory. Both systems operate very similarly for local transactions that only touch data "owned" by a single master region; they just relay the transaction to be executed by the master. For multi-region transactions, Spanner uses a coordinator to perform two-phase commit, which acquires locks on all regions before allowing the transaction to proceed. Slog does something similar, but effectively pipelines the locking to achieve higher throughput. First there's a global coordination step that globally-orders the transaction, without any locking (which means this step can use batching for high throughput). Then, each region's master independently acquires local locks in that global order, and replicates those locks as transactions so that replicas can deterministically apply them in the same order. Finally, each replica independently executes the transaction once it sees that all of the locks have been acquired. So a lock blocks the execution of conflicting transactions, but it doesn't block their replication. Once the replication is done, the locking overhead of actually executing the transactions should be comparable to a non-distributed DB. All of this communication has a latency penalty, of course; there's no avoiding that for a consistent distributed DB. But the point is that it provides better throughput for transactions with conflicts. For transactions that only touch one region, the latency is still just a single round-trip to the master region, and that can be very fast if your client locality is high. The benchmark results are heavily normalized, since it wasn't possible to do an apples-to-apples comparison on the same replication topology. So they don't demonstrate convincingly that Slog is faster than Spanner, in numerical terms. However, they do show that Spanner's throughput drops off much more quickly with increasing contention, compared to Slog. [1]: http://www.vldb.org/pvldb/vol12/p1747-ren.pdf http://www.vldb.org/pvldb/vol12/p1747-ren.pdf

by taldo 7y ago

abadid 7y ago

Let's say you have a transaction that writes data located in different quorums atomically. This is called a "multi-home" transaction in SLOG. Most of the machinery in the paper is dealing with that case. SLOG can do that with half-round trip latency. No idea how long it would take the version of Spanner you described to do that, but presumably at least two full round trips across quorums for two-phase commit.

teraflop 7y ago

The paper [1] compares Slog against Spanner, both in theoretical terms and using benchmarks. If I'm understanding the paper correctly, I think it makes sense why Slog is better -- or at least, can do better in theory. Both systems operate very similarly for local transactions that only touch data "owned" by a single master region; they just relay the transaction to be executed by the master. For multi-region transactions, Spanner uses a coordinator to perform two-phase commit, which acquires locks on all regions before allowing the transaction to proceed. Slog does something similar, but effectively pipelines the locking to achieve higher throughput. First there's a global coordination step that globally-orders the transaction, without any locking (which means this step can use batching for high throughput). Then, each region's master independently acquires local locks in that global order, and replicates those locks as transactions so that replicas can deterministically apply them in the same order. Finally, each replica independently executes the transaction once it sees that all of the locks have been acquired. So a lock blocks the execution of conflicting transactions, but it doesn't block their replication. Once the replication is done, the locking overhead of actually executing the transactions should be comparable to a non-distributed DB. All of this communication has a latency penalty, of course; there's no avoiding that for a consistent distributed DB. But the point is that it provides better throughput for transactions with conflicts. For transactions that only touch one region, the latency is still just a single round-trip to the master region, and that can be very fast if your client locality is high. The benchmark results are heavily normalized, since it wasn't possible to do an apples-to-apples comparison on the same replication topology. So they don't demonstrate convincingly that Slog is faster than Spanner, in numerical terms. However, they do show that Spanner's throughput drops off much more quickly with increasing contention, compared to Slog. [1]: http://www.vldb.org/pvldb/vol12/p1747-ren.pdf http://www.vldb.org/pvldb/vol12/p1747-ren.pdf