Do I read this email as "Jonathan will vote against any improvement to transactions that doesn't guarantee local latencies and interactive SQL, even though no such proposal exists, thereby blocking any improvement over the current status quo?"
On Thu, Oct 14, 2021 at 6:55 AM Jonathan Ellis <jbel...@gmail.com> wrote: > Hi Benedict, > > I'm not sure how to reconcile your statement that "your request to separate > consensus from execution is [nonsensical]" with your earlier claims that we > could build whatever additional transactional semantics we want on top of > Accord. The Accord whitepaper specifically separates out the consensus and > the execution algorithms, but if we can't use the former to create > execution timestamps for a different transaction manager then it doesn't > sound as flexible as you're claiming. > > To your other points, it looks like the core problem is that you believe > that "multi-shard CAS semantics" is the same as "Calvin semantics" which is > not the case. Calvin supports arbitrarily complex transactions (included > dependent statements and indexed reads and writes), executed in parallel, > with locking as necessary to enable that parallelism. > > I think I've also been clear that I want a path to supporting (1) local > latencies (SLOG is a more elegant solution but "let's just let people give > up global serializability like LWT" is also reasonable) and (2) SQL with > interactive transactions. > > I'd prefer to keep the discussion on the mailing list, thanks. > > > On Wed, Oct 13, 2021 at 3:04 AM bened...@apache.org <bened...@apache.org> > wrote: > > > Jonathan, > > > > Your request to separate consensus from execution is about as sensical as > > asking for this separation in Paxos, or any other distributed consensus > > protocol. I have made these statements repeatedly, so let me break it > down > > step by step. > > > > 1. Accord is an optimal leaderless distributed consensus protocol, > > offering multi-shard CAS semantics in one round-trip (or two under > > contention and clock skew). > > 2. By simple virtue of this property, it already achieves Calvin > semantics > > with no other work. It remains a distributed consensus protocol, and the > > whitepaper compares to these as peers. > > 3. To build distributed transactions with more complex semantics, the > > remaining candidates are the CockroachDB or YugaByte approach. These must > > utilise a distributed consensus protocol. They do so using Raft today. > > Accord is as optimal as Raft, therefore, Accord may be used to implement > > this technique *without penalty*. Through its multi-shard consensus it > has > > the added advantage of supporting stronger isolation (but not requiring > it > > – a read/write intent design may choose weaker isolation). > > > > You continue to refuse to engage with these and other points. Please > > respond directly to ALL of the below, that I have been asking you to > answer > > now for several weeks. > > > > 1. Since Accord supports all of your mooted transaction systems without > > penalty the conversation about which semantics to pursue may be conducted > > in parallel with its development. What about this claim do you not yet > > understand? If you understand, why should a vote on CEP-15 be delayed? > > 2. Which SPECIFIC transaction semantics do you want to achieve? You are > > all over the shop today, demanding Cockroach/YugaByte interactive > > semantics, but also LOCAL_SERIAL operation and proposing SLOG. These are > > conflicting demands. > > 3. Why do you think Accord cannot support your preferred semantics? > > 4. Will you accept a video call so we may discuss this with you in > detail, > > so we may understand your difficulty understanding these points I keep > > repeating? > > > > After several weeks of back and forth you should already be able to > answer > > these questions. If you cannot invest the time to answer them now, I > > perceive this as obstructive and I will escalate this to a PMC vote to > > break the deadlock. > > > > > > > > From: Jonathan Ellis <jbel...@gmail.com> > > Date: Wednesday, 13 October 2021 at 04:21 > > To: dev <dev@cassandra.apache.org> > > Subject: Re: Tradeoffs for Cassandra transaction management > > Blake (and Benedict), I’ll ask for your patience here. We don’t have a > > precedent of pushing through major initiatives in this project in a > matter > > of weeks. We [members of the PMC that weren’t involved in creating > Accord] > > need time to do thorough research and make sure both that we understand > > what is being proposed and that we have evaluated reasonable > alternatives. > > > > One of the difficulties in evaluating Accord is that it combines a > > state-of-the-art consensus/ordering protocol with a fairly limited > > transaction manager. So it may be useful to decouple the consensus and > > transaction processing components, which would both allow non-Cassandra > > usage of the consensus piece, and also make explicit the boundaries with > > transaction processing with the consequence of making it easier to evolve > > independently. > > > > In the meantime, it’s very important to me to understand on which > > dimensions the transaction manager can be improved easily, and which > > dimensions resist such improvement. I get that Accord is your [plural] > > baby and it’s awkward for me to come along and start pointing at its > > limitations, but that’s part of creating a complete understanding of any > > system. > > > > If I keep coming back to the subject of SQL support and interactive > > transactions, that’s because it’s becoming table stakes in the > distributed > > database space. People are using Cockroach or Yugabyte or Cloud Spanner > for > > use cases where a couple years ago they would have used Cassandra. We can > > expect this trend to continue and strengthen. > > > > On Mon, Oct 11, 2021 at 11:39 PM Blake Eggleston > > <beggles...@apple.com.invalid> wrote: > > > > > Let’s get back on topic. > > > > > > Jonathan, in your opening email you stated that, in your view, the 2 > main > > > areas of tradeoff were: > > > > > > > 1. Is it worth giving up local latencies to get full global > > consistency? > > > > > > Now we’ve established that we don’t need to give up local latencies > with > > > Accord, which leaves: > > > > > > > 2. Is it worth giving up the possibility of SQL support, to get the > > > benefits of deterministic transaction design? > > > > > > I pointed out that this was a false dilemma and that, in the worst > case, > > a > > > hypothetical SQL feature could have it’s own consensus system. I hope > > that > > > won’t be necessary, but as I later pointed out (and you did not > address, > > > although maybe I should have phrased it as a question), if we’re going > to > > > weigh accord against a hypothetical SQL feature that lacks design > goals, > > or > > > any clear ideas about how it might be implemented, how can we rule that > > out? > > > > > > So Jonathan, how can we rule that out? How can we have a productive > > > discussion about a feature you yourself are unable to describe in any > > > meaningful detail? > > > > > > > On Oct 11, 2021, at 6:34 PM, Jonathan Ellis <jbel...@gmail.com> > wrote: > > > > > > > > On Mon, Oct 11, 2021 at 5:11 PM bened...@apache.org < > > bened...@apache.org > > > > > > > > wrote: > > > > > > > >> If we want to fully unpack this particular point, as far as I can > tell > > > >> claiming ANSI SQL would indeed require interactive transactions in > > which > > > >> arbitrary conditional work may be performed by a client within a > > > >> transaction in response to other actions within that transaction. > > > >> > > > >> However: > > > >> > > > >> 1. The ANSI SQL standard permits these transactions to fail and > > > >> rollback (e.g. in the event that your optimistic transaction fails). > > So > > > if > > > >> you want to be pedantic, you may modify my statement to “SQL does > not > > > >> necessitate support for abort-free interactive transactions” and we > > can > > > >> leave it there. > > > >> > > > >> 2. I would personally consider “SQL support” to include the > > capability > > > >> of defining arbitrary SQL stored procedures that may be executed by > > > clients > > > >> in an interactive session > > > > > > > > > > > > I note your personal preference and I further note that this is not > the > > > > common understanding of "SQL support" in the industry. If you tell > 100 > > > > developers that your database supports SQL, then at least 99 of them > > are > > > > going to assume that you can work with APIs like JDBC that expose > > > > interactive transactions as a central feature, and hence that you > will > > be > > > > reasonably compatible with the vast array of SQL-based applications > out > > > > there. > > > > > > > > Historical side note: VoltDB tried to convince people that stored > > > > procedures were good enough. It didn't work, and VoltDB had to add > > > > interactive transactions as fast as they could. > > > > > > > > 3. Most importantly, as I pointed out in the previous email, Accord > > is > > > >> compatible with a YugaByte/Cockroach-like approach, and indeed makes > > > this > > > >> approach both easier to accomplish and enables stronger isolation > than > > > the > > > >> equivalent Raft-based approach. These approaches are able to reduce > > the > > > >> number of conflicts, at a cost of significantly higher transaction > > > >> management burden. > > > >> > > > > > > > > If you're saying that you could use Accord instead of Raft or Paxos, > > and > > > > layer 2PC on top of that as in Spanner, then I agree, but I don't > think > > > > that is a very good design, as you would no longer get any of the > > > benefits > > > > of the deterministic approach you started with. If you mean > something > > > > else, then perhaps an example would help clarify. > > > > > > > > -- > > > > Jonathan Ellis > > > > co-founder, http://www.datastax.com > > > > @spyced > > > > > > > > > --------------------------------------------------------------------- > > > To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org > > > For additional commands, e-mail: dev-h...@cassandra.apache.org > > > > > > > > > > -- > > Jonathan Ellis > > co-founder, http://www.datastax.com > > @spyced > > > > > -- > Jonathan Ellis > co-founder, http://www.datastax.com > @spyced >
