Adding a few notes from my perspective as well – Re: the UX question, thanks for asking this.I agree that offering a set of example queries and use cases may help make the specific use cases more understandable; perhaps we can prepare these as examples to be included in the CEP.I do think that all potential UX directions begin with the specification of the protocol that will underly them, as what can be expressed by it may be a superset of what's immediately exposed by CQL. But at minimum it's great to have a sense of the queries one might be able to issue to focus a reading of the whitepaper.Re: "Can we not start using it as an external dependency, and later re-evaluate if it's necessary to bring it into the project or even incubate it as another Apache
project"I think it would be valuable to the project for the work to be incubated in a separate repository as part of the Apache Cassandra project itself, much like the in-JVM dtest API and Harry. This pattern worked well for those projects as they incubated as it allowed them to evolve outside the primary codebase, but subject to the same project governance, set of PMC members, committers, and so on. Like those libraries, it also makes sense as the Cassandra project is the first (and at this time) only known intended consumer of the library, though there may be more in the future.If the proposal is accepted, the time horizon envisioned for this work's completion is ~9 months to a standard of production readiness. The contributors see value in the work
being donated to and governed by the contribution practices of the Foundation. Doing so ensures that it is being developed openly and with full opportunity for review and contribution of others, while also solidifying contribution of the IP to the project.Spinning up a separate ASF incubation project is an interesting idea, but I feel that doing so would introduce a far greater overhead in process and governance, and that the most suitable governance and set of committers/PMC members are those of the Apache Cassandra project itself.On Sep 14, 2021, at 3:53 PM, "bened...@apache.org" <bened...@apache.org> wrote:Hi Paulo,First and foremost, I believe this proposal in its current form focuses on the protocol details (HOW?) but lacks the bigger
picture on how this is going to be exposed to the user (WHAT)?In my opinion this CEP embodies a coherent distinct and complex piece of work, that requires specialist expertise. You have after all just suggested a month to read only the existing proposal 😊UX is a whole other kind of discussion, that can be quite opinionated, and requires different expertise. It is in my opinion helpful to break out work that is not tightly coupled, as well as work that requires different expertise. As you point out, multi-key UX features are largely independent of any underlying implementation, likely can be done in parallel, and even with different contributors.Can we not start using it as an external dependencyI would love to understand your rationale, as this is a surprising
suggestion to me. This is just like any other subsystem, but we would be managing it as a separate library primarily for modularity reasons. The reality is that this option should anyway be considered unavailable. This is a proposed contribution to the Cassandra project, which we can either accept or reject.Isn't this a good chance to make the serialization protocol pluggablewith clearly defined integration pointsIt has recently been demonstrated to be possible to build a system that can safely switch between different consensus protocols. However, this was very sophisticated work that would require its own CEP, one that we would be unable to resource. Even if we could this would be insufficient. This goal has never been achieved for a multi-shard transaction
protocol to my knowledge, and multi-shard transaction protocols are much more divergent in implementation detail than consensus protocols.so we could easily switch implementations with different guarantees… (ie. Apache Ratis)As far as I know, there are no other strict serializable protocols available to plug in today. Apache Ratis appears to be a straightforward Raft implementation, and therefore it is a linearizable consensus protocol. It is not multi-shard transaction protocol at all, let alone strict serializable. It could be used in place of Paxos, but not Accord.From: Paulo Motta <pauloricard...@gmail.com>Date: Tuesday, 14 September 2021 at 22:55To: Cassandra DEV <dev@cassandra.apache.org>Subject: Re: [DISCUSS] CEP-15: General Purpose
TransactionsI can start with some preliminary comments while I get more familiarizedwith the proposal:- First and foremost, I believe this proposal in its current form focuseson the protocol details (HOW?) but lacks the bigger picture on how this isgoing to be exposed to the user (WHAT)? Is exposing linearizabletransactions to the user not a goal of this proposal? If not, I think theproposal is missing the UX (ie. what CQL commands are going to be addedetc) on how these transactions are going to be exposed.- Why do we need to bring the library into the project umbrella? Can we notstart using it as an external dependency, and later re-evaluate if it'snecessary to bring it into the project or even incubate it as anotherApache project? I feel we may be importing
unnecessary management overheadinto the project while only a small subset of contributors will be involvedwith the core protocol.- Isn't this a good chance to make the serialization protocol pluggablewith clearly defined integration points, so we could easily switchimplementations with different guarantees, trade-offs and performanceconsiderations while leaving the UX intact? This would also allow us toeasily benchmark the protocol against alternatives (ie. Apache Ratis) andvalidate the performance claims. I think the best way to do that would beto define what the feature will look like to the end user (UX), define theintegration points necessary to support this feature, and use accord as thefirst implementation of these integration points.Em ter., 14 de set.
de 2021 às 17:57, Paulo Motta <pauloricard...@gmail.com>escreveu:Given the extensiveness and complexity of the proposal I'd suggest leavingit a little longer (perhaps 4 weeks from the publish date?) for people toget a bit more familiarized and have the chance to comment before casting avote. I glanced through the proposal - and it looks outstanding, verypromising work guys! - but would like a bit more time to take a deeper lookand digest it before potentially commenting on it.Em ter., 14 de set. de 2021 às 17:30, bened...@apache.org <bened...@apache.org> escreveu:Has anyone had a chance to read the drafts, and has any feedback orquestions? Does anybody still anticipate doing so in the near future? Orshall we move to a vote?From: bened...@apache.org
<bened...@apache.org>Date: Tuesday, 7 September 2021 at 21:27To: dev@cassandra.apache.org <dev@cassandra.apache.org>Subject: Re: [DISCUSS] CEP-15: General Purpose TransactionsHi Jake,> What structural changes are planned to support an external dependencyproject like thisTo add to Blake’s answer, in case there’s some confusion over this, theproposal is to include this library within the Apache Cassandra project. SoI wouldn’t think of it as an external dependency. This PMC and communitywill still have the usual oversight over direction and development, andAPIs will be developed solely with the intention of their integration withCassandra.> Will this effort eventually replace consistency levels in C*?I hope we’ll have some very related
discussions around consistency levelsin the coming months more generally, but I don’t think that is tightlycoupled to this work. I agree with you both that we won’t want toperpetuate the problems you’ve highlighted though.Henrik:> I was referring to the property that Calvin transactions also need tobe sent to the cluster in a single shotAh, yes. In that case I agree, and I tried to point to this direction inan earlier email, where I discussed the use of scripting languages (i.e.transactionally modifying the database with some subset of arbitrarycomputation). I think the JVM is particularly suited to offering quitepowerful distributed transactions in this vein, and it will be interestingto see what we might develop in this direction in future.From: Jake
Luciani <jak...@gmail.com>Date: Tuesday, 7 September 2021 at 19:27To: dev@cassandra.apache.org <dev@cassandra.apache.org>Subject: Re: [DISCUSS] CEP-15: General Purpose TransactionsGreat thanks for the informationOn Tue, Sep 7, 2021 at 12:44 PM Blake Eggleston<beggles...@apple.com.invalid> wrote:> Hi Jake,>> > 1. Will this effort eventually replace consistency levels in C*? Iask> > because one of the shortcomings of our paxos today is> > it can be easily mixed with non serialized consistencies and therefore> > users commonly break consistency by for example reading at CL.ONEwhile> > also> > using LWTs.>> This will likely require CLs to be specified at the schema level for> tables using multi
partition transactions. I’d expect this to beavailable> for other tables, but not required.>> > 2. What structural changes are planned to support an externaldependency> > project like this? Are there some high level interfaces you expectthe> > project to adhere to?>> There will be some interfaces that need to be implemented in C* tosupport> the library. You can find the current interfaces in the accord.apipackage,> but these were written to support some initial testing, and not intended> for integration into C* as is. Things are pretty fluid right now andwill> be rewritten / refactored multiple times over the next few months.>> Thanks,>> Blake>>> > On Sun, Sep 5, 2021 at 10:33 AM
bened...@apache.org <bened...@apache.org> >> > wrote:> >> >> Wiki:> >>>https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-15%3A+General+Purpose+Transactions> >> Whitepaper:> >>>https://cwiki.apache.org/confluence/download/attachments/188744725/Accord.pdf> >> <> >>>https://cwiki.apache.org/confluence/download/attachments/188744725/Accord.pdf?version=1&modificationDate=1630847736966&api=v2> >>>> >> Prototype: https://github.com/belliottsmith/accord> >>> >> Hi everyone, I’d like to propose this CEP for adoption by thecommunity.> >>> >> Cassandra has benefitted from LWTs for many years, but application>
>> developers that want to ensure consistency for complex operationsmust> >> either accept the scalability bottleneck of serializing all related> state> >> through a single partition, or layer a complex state machine on topof> the> >> database. These are sophisticated and costly activities that ourusers> >> should not be expected to undertake. Since distributed databases are> >> beginning to offer distributed transactions with fewer caveats, it is> past> >> time for Cassandra to do so as well.> >>> >> This CEP proposes the use of several novel techniques that build upon> >> research (that followed EPaxos) to deliver (non-interactive) general> >> purpose
distributed transactions. The approach is outlined in the> wikipage> >> and in more detail in the linked whitepaper. Importantly, by adopting> this> >> approach we will be the _only_ distributed database to offer global,> >> scalable, strict serializable transactions in one wide arearound-trip.> >> This would represent a significant improvement in the state of theart,> >> both in the academic literature and in commercial or open source> offerings.> >>> >> This work has been partially realised in a prototype. This partial> >> prototype has been verified against Jepsen.io’s Maelstrom library and> >> dedicated in-tree strict serializability verification tools, but much>
work> >> remains for the work to be production capable and integrated into> Cassandra.> >>> >> I propose including the prototype in the project as a new source> >> repository, to be developed as a standalone library for integrationinto> >> Cassandra. I hope the community sees the important value propositionof> >> this proposal, and will adopt the CEP after this discussion, so thatthe> >> library and its integration into Cassandra can be developed inparallel> and> >> with the involvement of the wider community.> >>> >> >> > --> > http://twitter.com/tjake>>> ---------------------------------------------------------------------> To
unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org> For additional commands, e-mail: dev-h...@cassandra.apache.org>>--http://twitter.com/tjake
