4 ms·

(I work for Google Cloud) Half this paper covers what happens during a network partition, the other part talks about the historic data backing up the claims th

(I work for Google Cloud) Half this paper covers what happens during a network partition, the other part talks about the historic data backing up the claims that they are super rare. There is even a whole section called "What happens during a Partition". On the first page: > The purist answer is “no” because partitions can happen and in fact have happened at Google, and during (some) partitions, Spanner chooses C and forfeits A. It is technically a CP system. We explore the impact of partitions below. And the conclusion states as a fact that outages will occur: > Spanner reasonably claims to be an “effectively CA” system despite operating over a wide area, as it is always consistent and achieves greater than 5 9s availability. As with Chubby, this combination is possible in practice if you control the whole network, which is rare over the wide area. Even then, it requires significant redundancy of network paths, architectural planning to manage correlated failures, and very careful operations, especially for upgrades. Even then outages will occur, in which case Spanner chooses consistency over availability.

zzzcpan 9y ago
You can think of this a bit differently, that the network is asynchronous and is effectively always partitioned. This helps to highlight the trade offs between CP and AP, since it becomes obvious that you need to wait to get consistency and if you don't wait you can get it only eventually. Also becomes obvious that CA systems cannot actually exist, and 5 9s availability has absolutely nothing to do with any of that.
- muxator 9y ago
  Fair point. This is a very clever way of looking at it, thanks.
- theptip 9y ago
  This is a much more sophisticated way of carving up the problem -- for those interested in reading more, Kleppmann has discussed this extensively: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html https://martin.kleppmann.com/2015/05/11/please-stop-calling-...
manigandham 9y ago
That's my point. Overall this paper tries to make the case for "effectively CA" which is not real. It's a marketing tactic that basically just adds confusion to the conversation. If you want to talk about the fantastic reliability of the infrastructure, that's a separate topic than data availability during a failure.

zzzcpan 9y ago

You can think of this a bit differently, that the network is asynchronous and is effectively always partitioned. This helps to highlight the trade offs between CP and AP, since it becomes obvious that you need to wait to get consistency and if you don't wait you can get it only eventually. Also becomes obvious that CA systems cannot actually exist, and 5 9s availability has absolutely nothing to do with any of that.

muxator 9y ago
Fair point. This is a very clever way of looking at it, thanks.
theptip 9y ago
This is a much more sophisticated way of carving up the problem -- for those interested in reading more, Kleppmann has discussed this extensively: https://martin.kleppmann.com/2015/05/11/please-stop-calling-databases-cp-or-ap.html https://martin.kleppmann.com/2015/05/11/please-stop-calling-...

manigandham 9y ago

That's my point. Overall this paper tries to make the case for "effectively CA" which is not real. It's a marketing tactic that basically just adds confusion to the conversation. If you want to talk about the fantastic reliability of the infrastructure, that's a separate topic than data availability during a failure.