5 ms·
CTO of YugaByte here. We firmly stand by our claims, and I wanted to explain more. From the post by Daniel: << CockroachDB, to its credit, has acknowledged tha
by rkarthik007 8y ago
CTO of YugaByte here. We firmly stand by our claims, and I wanted to explain more.
From the post by Daniel:
<< CockroachDB, to its credit, has acknowledged that by only incorporating Spanner’s software innovations, the system cannot guarantee CAP consistency (which, as mentioned above, is linearizability).
YugaByte, however, continues to claim a guarantee of consistency. I would advise people not to trust this claim. YugaByte, by virtue of its Spanner roots, will run into consistency violations when the local clock on a server suddenly jumps beyond the skew uncertainty window. >>
The statement about YugaByte DB is incorrect.
1. With respect to CAP, both Cockroach DB (https://www.cockroachlabs.com/blog/limits-of-the-cap-theorem/ https://www.cockroachlabs.com/blog/limits-of-the-cap-theorem...) and YugaByte DB (https://docs.yugabyte.com/latest/faq/architecture/#how-can-yugabyte-db-be-both-cp-and-ha-at-the-same-time https://docs.yugabyte.com/latest/faq/architecture/#how-can-y...) are CP databases with HA and there is really no difference in the claims.
2. With respect to Isolation level in ACID, YugaByte DB does not make the linearizability (called external consistency by Google Spanner) claim. YugaByte DB offers Snapshot Isolation (detects write-write conflicts) today and Serializable isolation (detect read-write and write-write conflicts) is in the roadmap (https://docs.yugabyte.com/latest/architecture/transactions/isolation-levels/ https://docs.yugabyte.com/latest/architecture/transactions/i...).
3. We have publicly claimed that we do rely on NTP and max clock skew bounds to guarantee consistency. For example, slide 43 of our NorCal DB Day talk (https://www.slideshare.net/YugaByte/yugabyte-db-architecture-storage-engine-and-transactions https://www.slideshare.net/YugaByte/yugabyte-db-architecture...) we mention we are “relying on bounded clock sync (NTP, AWS Time Sync, etc).”
- abadid 8y agoLooks like you cross-posted this comment here and on my blog, so I'll also cross-post in my response. I am quite confused by your statement that YugaByte does not claim linearizability. The C of CAP is linearizability (see the original CAP theorem https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.pdf https://users.ece.cmu.edu/~adrian/731-sp04/readings/GL-cap.p...). By claiming to be CP from CAP, you are claiming linearizability. CockroachDB also makes the same CP claim. However, they explicitly walk back from this claim (https://www.cockroachlabs.com/blog/living-without-atomic-clocks/ https://www.cockroachlabs.com/blog/living-without-atomic-clo...). In contrast, YugaByte documentation makes no effort to walk back from this claim. Rather, the documentation seems to indicate that YugaByte is linearizable at: https://blog.yugabyte.com/jepsen-testing-on-yugabyte-db-database/ https://blog.yugabyte.com/jepsen-testing-on-yugabyte-db-data... and https://docs.yugabyte.com/latest/develop/learn/acid-transactions/ https://docs.yugabyte.com/latest/develop/learn/acid-transact.... Also, I would encourage you to read the Herlihy-Wing paper on linearizability published in 1990. You seem to be confusing linearizability with ACID isolation levels, which are actually a different concept. Peter Bailis has a good blog post on the difference: http://www.bailis.org/blog/linearizability-versus-serializability/ http://www.bailis.org/blog/linearizability-versus-serializab.... On your third point, we agree. However, the point of my post is that relying on max clock skew without hardware support is dangerous. I’m going so far as to say that it’s so dangerous that it is incorrect to claim consistency guarantees when you make such assumptions. I would really encourage YugaByte to consider using global consensus instead of partitioned consensus. I believe you will find it much easier to support serializability (which as you said, is on your road map) and linearizability.
- rkarthik007 8y agoWill cross-post as well - unclear about protocols here :) From the Peter Bailis link you had: > Linearizability is a guarantee about single operations on single objects. Our references to "linearizability" in the Jepsen blog and the docs are in the context of single key operations; happy to update to update our docs to clarify that further. For multi-key transactions in YugaByte DB, our docs clearly point out that we offer Snapshot Isolation today and Serializable Isolation is in our roadmap (https://docs.yugabyte.com/latest/architecture/transactions/isolation-levels/ https://docs.yugabyte.com/latest/architecture/transactions/i...).
- rkarthik007 8y agoHN ate my comment, hope to figure hn out someday! Had written: From the bailis.org link you posted: > Linearizability is a guarantee about single operations on single objects. The place we references "linearizability" (in the Jepsen blog and docs) are in the context of single row-key operations; I can update our docs to clarify that further. For multi-key transactions, our docs clearly point out that we support Snapshot Isolation now and Serializable Isolation is in the roadmap.
- kmuthukk 8y agoKarthik's response to this comment is on the original blog here: http://dbmsmusings.blogspot.com/2018/09/newsql-database-systems-are-failing-to.html?showComment=1537571027365#c6713546973614848548 http://dbmsmusings.blogspot.com/2018/09/newsql-database-syst...