3 ms·
It may not be up to date at the time of actually READING the data, but it will be up to date if the date is the moment the client requested it. You can actually
by cube2222 10y ago
It may not be up to date at the time of actually READING the data, but it will be up to date if the date is the moment the client requested it. You can actually achieve this using timestamps. (So basically, it's semi-stale data, you're right, because you have a guarantee about the timestamp at which it was up to date, where the timestamp can be recent)
(Not talking about etcd, check out the spanner paper)
- sseveran 10y agoTrueTime is a very special case. I have not seen anyone else who has the same hardware infrastructure required to provide guarantees related to wall-clock time. Spanner also trades off transaction latency to create the wall clock time guarantees, so its not magically free.
- cube2222 10y agoIt isn't, I haven't said it is. The point is, there are disadvantages you are writing about, that aren't really disadvantages of the protocol itself, but disadvantages of the common implementations.
- rescrv 10y agoIn order to get a linearizable read in Spanner, you do need to have a heartbeat from the leader of the Paxos tablet for the data you are reading in order to know that all data has been replicated up to the time at which you are taking your read. This is not free, but can be cheaper than active communication. (referred to as t_safe in the paper)
- cube2222 10y agoAs I understood it, if you are actually reading at some point it time (let's say 100 ms ago), then the non-leader node can check for himself, if he was in contact with the master after this point of time and give you an answer.
- rystsov 10y agoYes that's true if all the communication between agents goes through the database then the Monotonic Reads consistency level is equivalent to linearizability. In case there are off the database communications then this level of consistency isn't enough.