“Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
1–10 of 29 posts
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#2For reference, this is part 2 of a two part series. Here is part 1: https://www.cockroachlabs.com/blog/tunable-controls-for-late...
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#3So is this for helping with read, but not write latency?
I know little about CockroachDB, but I vaguely remember that it has consistent replication. If so, then writes would require some round trips before consensus is reached, killing any latency benefits from having the master follow the load (unless you move all your replicas around!).
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#4So is this for helping with read, but not write latency? I know little about CockroachDB, but I vaguely remember that it has consistent replication. If so, then writes would require some round trips before consensus is reached, killing any latency benefits from having the master follow the load (unless you move all your replicas around!).
It helps with both, but is more dramatic for reads.
Reads go from 1 RTT to 0 RTTs, while writes go from 2 RTTs to 1 RTT. For example, consider a cluster in which the nodes are 200ms RTT away from each other.
* A read will take 200ms if the leaseholder isn't in the local datacenter vs single-digit milliseconds if it is local.
* A write will take 400ms if the leaseholder isn't in the local datacenter vs 200 milliseconds if it is local.
The write takes 400ms because it takes 100ms to get from the local datacenter to leaseholder, 200ms to reach consensus (the leaseholder needs to send a request to and get a response from one of the followers), and another 100ms for the response from the leaseholder to get back to the local datacenter where the request originated.
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#5I always longed for the existence of such an Ops-friendly DB, which - building on solid distributed systems concepts - could make easy and correct the hard things (consistency, geographical replication, effective possibility of zero downtime).
Now that I have a good candidate, I find myself wondering whether the performances would be good enough to ditch traditional DBs (I know: I should define "workload" before thinking about "performances"...)
I guess is the curse of tradeoffs: nothing in life is free.
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#6So is this for helping with read, but not write latency? I know little about CockroachDB, but I vaguely remember that it has consistent replication. If so, then writes would require some round trips before consensus is reached, killing any latency benefits from having the master follow the load (unless you move all your replicas around!).
It helps with both, but is more dramatic for reads. Reads go from 1 RTT to 0 RTTs, while writes go from 2 RTTs to 1 RTT. For example, consider a cluster in which the nodes are 200ms RTT away from each other. * A read will take 200ms if the leaseholder isn't in the local datacenter vs single-digit milliseconds if it is local. * A write will take 400ms if the leaseholder isn't in the local datacenter vs 200 millisecond…
Really looking forward to see this in action. Is follow the workload already present in 1.1.3?
Is there a bit more detailed technical doc on how this is actually achieved ideally with some examples? When is it decided that the lease holder moves from one node to another? Is it based on some sort of stats?
Edit: found the doc follow-the-workload here: https://www.cockroachlabs.com/docs/stable/demo-follow-the-wo...
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#7Earlier quoted context omitted.
It helps with both, but is more dramatic for reads. Reads go from 1 RTT to 0 RTTs, while writes go from 2 RTTs to 1 RTT. For example, consider a cluster in which the nodes are 200ms RTT away from each other. * A read will take 200ms if the leaseholder isn't in the local datacenter vs single-digit milliseconds if it is local. * A write will take 400ms if the leaseholder isn't in the local datacenter vs 200 millisecond…
Really looking forward to see this in action. Is follow the workload already present in 1.1.3? Is there a bit more detailed technical doc on how this is actually achieved ideally with some examples? When is it decided that the lease holder moves from one node to another? Is it based on some sort of stats? Edit: found the doc follow-the-workload here: https://www.cockroachlabs.com/docs/stable/demo-follow-the-wo...
It's actually even in 1.0.0! We just haven't written about it previously.
The doc you found is the best resource. If you want even more detail, you can check out the original RFC: https://github.com/cockroachdb/cockroach/blob/master/docs/RF...
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#8Cockroachdb looks very exciting. I’m waiting for it’s Postgres compatibility to be far enough along that it works with Elixir/Phoenix. Is that likely to happen any time soon?
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#9Can anyone elaborate as to how CockroachDB compares to Scylla? It seems to me like they're very similar on a surface level.
Re: “Follow-The-Workload” Beats the Latency-Survivability Tradeoff in CockroachDB
#10Can anyone elaborate as to how CockroachDB compares to Scylla? It seems to me like they're very similar on a surface level.
They're pretty different. Scylla is essentially a C++ rewrite of Cassandra, while CockroachDB aims to be a true distributed SQL database. Cassandra and Scylla do not support transactions (or atomicity or strong consistency) or joins.