3 ms·

>I like PACELC because it helps you to think about consistency in the common case, when your database is operating normally. Can you handle the occasional stale

>I like PACELC because it helps you to think about consistency in the common case, when your database is operating normally. Can you handle the occasional stale read, and in which situations? If not, are you fine with the increased latency and reduced availability that strong consistency requires? Using that assumption - no partition - why can't we determine if a bit data on a node is stale and request it from somewhere else?

rgbrenner 4y ago
Let me ask a different question (to answer your question): How will you determine if the data is stale? Think through the options here: 1) When one node writes new data, it'll notify the other nodes that it wrote data. Thats called eventual consistency, and you'll get stale reads.. because of the latency between the time the item is written and the time the remote nodes get notified of the update. 2) On write, you make sure all of the nodes accept the update. This is strong consistency, with all of the positives and negatives that includes (high latency, reduced availability). 3) On read, you check with all of the nodes for the newest data. This is another form of strong consistency. If you weaken the last one, and say: I'll set a timeout, so if there's a network error (even without a partition, there could be a network error) it doesn't block... if that timeout is triggered, then you havent checked all of the nodes, and so you dont know if it's stale (in some cases it will be). There's literally no way to guarantee the data is not stale without strong consistency... and the laws of nature are the reason why. Data cannot be transmitted instantaneously. Therefore you have to handle that delay somewhere. You can accept stale reads (eventual consistency), or you can accept high latency reads or commits (strong consistency). But the latency never disappears.

rgbrenner 4y ago

Let me ask a different question (to answer your question): How will you determine if the data is stale? Think through the options here: 1) When one node writes new data, it'll notify the other nodes that it wrote data. Thats called eventual consistency, and you'll get stale reads.. because of the latency between the time the item is written and the time the remote nodes get notified of the update. 2) On write, you make sure all of the nodes accept the update. This is strong consistency, with all of the positives and negatives that includes (high latency, reduced availability). 3) On read, you check with all of the nodes for the newest data. This is another form of strong consistency. If you weaken the last one, and say: I'll set a timeout, so if there's a network error (even without a partition, there could be a network error) it doesn't block... if that timeout is triggered, then you havent checked all of the nodes, and so you dont know if it's stale (in some cases it will be). There's literally no way to guarantee the data is not stale without strong consistency... and the laws of nature are the reason why. Data cannot be transmitted instantaneously. Therefore you have to handle that delay somewhere. You can accept stale reads (eventual consistency), or you can accept high latency reads or commits (strong consistency). But the latency never disappears.