3 ms·

To be fair to the article, It's pretty upfront about the constraints. From the article: 'Of course, there are several guarantees that HATs cannot provide. Not

To be fair to the article, It's pretty upfront about the constraints. From the article: 'Of course, there are several guarantees that HATs cannot provide. Not even the best of marketing teams can produce a real database that “beats CAP”; HATs cannot make guarantees on data recency during partitions, although, in the absence of partitions, data may not be very stale. HATs cannot be “100% ACID compliant” as they cannot guarantee serializability' My concern is the pitched low latency use case, if I understand correctly there's no way to avoid an extra round trip? Could be very useful all the same.

pbailis 14y ago
> if I understand correctly there's no way to avoid an extra round trip? With HATs, you only need to contact one replica for every key. This is to goal behind our definition of "high availability" (http://www.bailis.org/blog/hat-not-cap-introducing-highly-available-transactions/#availability-note http://www.bailis.org/blog/hat-not-cap-introducing-highly-av...). In general, I haven't seen algorithms guaranteeing serializability or atomicity that complete without a round trip to at least one other replica (or a possibly long trip to the master). Intuitively, the impossibility results dictate that this must be the case, otherwise partitioned replicas could safely serve requests. Daniel Abadi has a great post about this latency-consistency trade-off: http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-and-yahoos-little.html http://dbmsmusings.blogspot.com/2010/04/problems-with-cap-an...