Re: [DISCUSS] CEP-15: General Purpose Transactions
We have discussed the API at length in this thread. The API primarily involves the semantics of the transactions, as besides this the API of a transaction is simply: Result perform(Transaction transaction) As discussed in follow-up to that email, a prototype API is specified alongside the prototype protocol. I am unsure what more you want than this, or the above, or the prior semantic discussions. It seems clear that you’re unhappy with the proposal, but it remains ambiguous as to why. Your emails are terse, infrequent and unclear. My responses receive no follow up from you, even to clarify if I have answered your query. Sometime later I seem to be able to expect a new unrelated problem that you are unhappy about. You have not yet responded to even one of my repeated offers to hop on a call to hash out any of your concerns, even if only to decline. This does not feel like constructive and respectful engagement to me, and I am losing interest. From: Jonathan Ellis Date: Wednesday, 6 October 2021 at 00:02 To: dev Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions I honestly can't understand the perspective that on the one hand, you're asking for approval of a specific protocol as part of the CEP, but on the other, you think discussion of the APIs this will enable is not warranted. Surely we need agreement on what APIs we're trying to build, before we discuss the protocols and architectures with which to build them. On Fri, Oct 1, 2021 at 9:34 AM bened...@apache.org wrote: > > The current document details thoroughly the protocol but in my view > lacks to illustrate what specific API, methods, modules will become > available to developers > > With respect to this, in my view this kind of detail is not warranted > within a CEP. Software development is an exploratory process with respect > to structure, and these decisions will be made as the CEP progresses. If > these need to be specified upfront, then the purpose of a CEP – seeking buy > in – is invalidated, because the work must be complete before you know the > answers. > > > From: bened...@apache.org > Date: Friday, 1 October 2021 at 15:31 > To: dev@cassandra.apache.org > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > From the CEP: > > Batches (including unconditional batches) on transactional tables will > receive ACID properties, and grammatically correct conditional batch > operations that would be rejected for operating over multiple CQL > partitions will now be supported > > > From: Paulo Motta > Date: Friday, 1 October 2021 at 15:30 > To: Cassandra DEV > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > Can you just answer what palpable feature will be available once this CEP > lands because this is still not clear to me (and perhaps to others) from > the current CEP structure. The current document details thoroughly the > protocol but in my view lacks to illustrate what specific API, methods, > modules will become available to developers, how it fits into the larger > picture and interacts with existing modules if at all and perhaps a few > examples of how it can be used to build features on top. > > Em sex., 1 de out. de 2021 às 11:10, bened...@apache.org < > bened...@apache.org> escreveu: > > > I’m not, though it might seem that way. I disagree with your views about > > how CEP should be structured. Since the CEP process was itself codified > via > > the CEP process, if you want to recodify how CEP work, the correct way is > > via the CEP process itself. > > > > The discussion is being drawn in multiple directions away from the CEP > > itself, and I am trying to keep this particular thread focused on the > > business at hand, not meta discussions around CEP structure that will no > > doubt be unproductive given likely irreconcilable views about the topic, > > nor discussions about other CEP that could have been. > > > > If you want to start a separate exploratory discussion thread about CEP > > structure without filing a CEP feel free to do so. > > > > > > From: Paulo Motta > > Date: Friday, 1 October 2021 at 15:04 > > To: Cassandra DEV > > Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions > > > If you want to impose your views on CEP structure on others, please > file > > a CEP with the additional restrictions and guidance you want to impose > and > > start a discussion thread. I can then respond in detail to why I perceive > > this approach to be flawed, in a dedicated context. > > > > This sounds very kafkaesque. You know I won't file a meta-CEP to change > the > > structure of CEP so you're just using this as an excuse to just shut the > > discussion on the lack of clarity on what actual palpable feature will be > > available once the CEP lands. :-) > > > > I'm just providing my humble feedback on how a CEP could be more > digestible > > and easier to consume from an external point of view, and this seems like > > an appropriate and contextualized place to voice this opin
Re: [DISCUSS] Cleaning up docs, completing CASSANDRA-16763
Thanks Lorina for all your work. +1 Your proposal makes sense to me. Le mer. 6 oct. 2021 à 00:34, Lorina Poland a écrit : > This is a discussion about how to tackle getting the docs “fixed”. > > As many of you know, I started months ago to convert the Apache Cassandra > in-tree docs > from reStructedText (rST)to AsciiDoc. [1] > The conversion required both the docs source files to be converted, but > also the cassandra-website > source to be updated, to build the docs from AsciiDoc.[2] You all have seen > the results of that > conversion + the beautiful new design work accomplished. > When Apache Cassandra 4.0 was ready to GA, we used my private repo > (polandll/cassandra) to build the docs for > publication. (The new cassandra-website procedure allows for any repo to be > used to build.) > Due to a series of interferences with virtually all the people on the > project > (myself, Anthony Grasso, Mick Semb Wever, Paul Lau) in the time leading up > to the GA or right after, > we have never gotten my repo work committed and merged to the official > source (apache/cassandra). > So, here is the proposal for a plan of action: > > (1) Anthony and Lorina get the 4.0/trunk and 3.11 branches that Lorina > worked on for the last 18 months > ready for merge from polandll/cassandra -> apache/cassandra. > (2) There are changes that were made in the last 18 months to docs (in the > current rST docs) that need > to be backported to the new adoc docs. We can use the commit history to > hunt down those changes and make > tickets for each of them. Those tickets can be listed under an umbrella > ticket. > (3) There are tickets that already exist that I asked people to wait on > merging during the conversion. > Those tickets also need to be completed. > (4) There are a few tickets for PRs people submitted to my private repo (oh > my!) that should be completed > again in the official repo. > (5) I will write a “how to contribute to docs” that gives people a rundown > of how to write AsciiDoc. > > We would like to merge the docs in their current state, step (1), then make > the backports, rather than make the > backports then merge to the apache/cassandra repo. Main reason for this > order is that, at least the docs > and website could be built from official repos once that is done. Until the > adoc conversion is merged, > the docs and website can only be built from my personal repo, which is a > sad situation. > > Lastly, just to clarify the work we want to merge. I modified the trunk for > 4.0 and made all the changes > required. (750+ files). Then, rather than modify the 3.11 branch, I wrote > trunk to 3.11 and > removed the “What’s new” folder (called /new, unimaginatively). I had > planned to then go back and > incorporate the "What’s new" material into the appropriate places in the > 4.0 docs, because, in short order, > those changes are no longer what’s new. > > [1] > > https://lists.apache.org/thread.html/r42802f86d7893c42b5091fe7f7d4b048a63cbe0fd11fadcd120596e3%40%3Cdev.cassandra.apache.org%3E > [2] > > https://lists.apache.org/thread.html/r961c52f58a42a3b2cae7299244a525311283cd2758d0201f8b0feb83%40%3Cdev.cassandra.apache.org%3E >
[DISCUSS] CASSANDRA-17024: Artificial Latency Injection
Hi Everyone, This is a modest user-facing feature that I want to highlight in case anyone has any input. In order to validate if a real cluster may modify its topology or consistency level (e.g. from local to global), this ticket introduces a facility for injecting latency to internode messages. This is particularly helpful for high-availability topologies, and in particular for LWTs (where performance may be unpredictable due to contention), so that real traffic may be modified to experience gradually increasing latency in order to validate a topology (or the impact of a global consistency level) before any transition is undertaken. The user-visible changes include new config parameters, new JMX end points for modifying these parameters, and new consistency levels that may be supplied to mark queries as suitable for latency injection (so that applications may nominate queries for this mechanism)
Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
This sounds like a great feature! I wonder if Consistencylevel is the best way to expose this to users though, can't we implement this via another driver/protocol option ? Ie. "delay_enabled" flag that would be a modifier to an existing CL. If we decide to go the CL route, I wonder if this isn't a good opportunity to introduce pluggable consistency levels (CASSANDRA-8119 < https://issues.apache.org/jira/browse/CASSANDRA-8119>) so these would only become available when the feature is enabled. My concern here is adding niche consistency levels to the default CL table which may create confusion to non-power users. Em qua., 6 de out. de 2021 às 10:12, bened...@apache.org < bened...@apache.org> escreveu: > Hi Everyone, > > This is a modest user-facing feature that I want to highlight in case > anyone has any input. In order to validate if a real cluster may modify its > topology or consistency level (e.g. from local to global), this ticket > introduces a facility for injecting latency to internode messages. This is > particularly helpful for high-availability topologies, and in particular > for LWTs (where performance may be unpredictable due to contention), so > that real traffic may be modified to experience gradually increasing > latency in order to validate a topology (or the impact of a global > consistency level) before any transition is undertaken. > > The user-visible changes include new config parameters, new JMX end points > for modifying these parameters, and new consistency levels that may be > supplied to mark queries as suitable for latency injection (so that > applications may nominate queries for this mechanism) > > >
Re: [DISCUSS] CEP-15: General Purpose Transactions
I've repeatedly explained why I'm unhappy: instead of starting with a
discussion of what API and tradeoffs we should make to get that, this CEP
starts with a protocol and asks us to figure out what API we can build with
it.
Of course by API I mean, what kinds of CQL and SQL operations we can
perform, with what kinds of ACID semantics and what kinds of performance,
not "Result perform(Transaction transaction)". And it's not simply SQL
syntax, either. I realize that this could sound a little vague, but that's
why I gave an example of the kind of analysis I'm talking about in my first
reply. Your responses have been to attempt to avoid the discussion
entirely ("the relevant goals are [mine]") or to declare it to be out of
scope.
The CEP process is intended to help get to alignment across the community
of PMC members, committers, and contributors on goals and outcomes before
starting in writing code, not simply to bless a completed design. That's
why we're going in circles here.
On Wed, Oct 6, 2021 at 2:12 AM bened...@apache.org
wrote:
> We have discussed the API at length in this thread. The API primarily
> involves the semantics of the transactions, as besides this the API of a
> transaction is simply:
>
> Result perform(Transaction transaction)
>
> As discussed in follow-up to that email, a prototype API is specified
> alongside the prototype protocol. I am unsure what more you want than this,
> or the above, or the prior semantic discussions.
>
> It seems clear that you’re unhappy with the proposal, but it remains
> ambiguous as to why. Your emails are terse, infrequent and unclear. My
> responses receive no follow up from you, even to clarify if I have answered
> your query. Sometime later I seem to be able to expect a new unrelated
> problem that you are unhappy about. You have not yet responded to even one
> of my repeated offers to hop on a call to hash out any of your concerns,
> even if only to decline.
>
> This does not feel like constructive and respectful engagement to me, and
> I am losing interest.
>
>
>
> From: Jonathan Ellis
> Date: Wednesday, 6 October 2021 at 00:02
> To: dev
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> I honestly can't understand the perspective that on the one hand, you're
> asking for approval of a specific protocol as part of the CEP, but on the
> other, you think discussion of the APIs this will enable is not warranted.
> Surely we need agreement on what APIs we're trying to build, before we
> discuss the protocols and architectures with which to build them.
>
> On Fri, Oct 1, 2021 at 9:34 AM bened...@apache.org
> wrote:
>
> > > The current document details thoroughly the protocol but in my view
> > lacks to illustrate what specific API, methods, modules will become
> > available to developers
> >
> > With respect to this, in my view this kind of detail is not warranted
> > within a CEP. Software development is an exploratory process with respect
> > to structure, and these decisions will be made as the CEP progresses. If
> > these need to be specified upfront, then the purpose of a CEP – seeking
> buy
> > in – is invalidated, because the work must be complete before you know
> the
> > answers.
> >
Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
On Wed, Oct 6, 2021 at 8:37 AM Paulo Motta wrote: > > This sounds like a great feature! I agree, this is going to be very useful. > I wonder if Consistencylevel is the best way to expose this to users > though, can't we implement this via another driver/protocol option ? Ie. > "delay_enabled" flag that would be a modifier to an existing CL. I too worry about adding more CLs, especially 'special' ones like these. > If we decide to go the CL route, I wonder if this isn't a good opportunity > to introduce pluggable consistency levels (CASSANDRA-8119 < > https://issues.apache.org/jira/browse/CASSANDRA-8119>) so these would only > become available when the feature is enabled. I think it would be great to finally make CLs pluggable. There has already been a good amount of demand there. > My concern here is adding niche consistency levels to the default CL table > which may create confusion to non-power users. I agree. No matter how obviously we name them, someone will unknowingly use them, potentially generating some deep rabbit holes to go down with troubleshooting. - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
This is a very good point. I forget the reason we settled on consistency levels, I assume it was due to simplicity of the solution, as deploying support for a new protocol-level change is more involved. That’s probably not a good reason here, and I agree that overloading consistency level feels wrong. I hope we will retire user-provided consistency levels over the coming year or two, which is another good reason not to begin enhancing it with new meanings. I will rework the ticket and patches. From: Paulo Motta Date: Wednesday, 6 October 2021 at 14:37 To: Cassandra DEV Subject: Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection This sounds like a great feature! I wonder if Consistencylevel is the best way to expose this to users though, can't we implement this via another driver/protocol option ? Ie. "delay_enabled" flag that would be a modifier to an existing CL. If we decide to go the CL route, I wonder if this isn't a good opportunity to introduce pluggable consistency levels (CASSANDRA-8119 < https://issues.apache.org/jira/browse/CASSANDRA-8119>) so these would only become available when the feature is enabled. My concern here is adding niche consistency levels to the default CL table which may create confusion to non-power users. Em qua., 6 de out. de 2021 às 10:12, bened...@apache.org < bened...@apache.org> escreveu: > Hi Everyone, > > This is a modest user-facing feature that I want to highlight in case > anyone has any input. In order to validate if a real cluster may modify its > topology or consistency level (e.g. from local to global), this ticket > introduces a facility for injecting latency to internode messages. This is > particularly helpful for high-availability topologies, and in particular > for LWTs (where performance may be unpredictable due to contention), so > that real traffic may be modified to experience gradually increasing > latency in order to validate a topology (or the impact of a global > consistency level) before any transition is undertaken. > > The user-visible changes include new config parameters, new JMX end points > for modifying these parameters, and new consistency levels that may be > supplied to mark queries as suitable for latency injection (so that > applications may nominate queries for this mechanism) > > >
Re: [DISCUSS] CEP-15: General Purpose Transactions
The goals of the CEP are stated clearly, and these were the goals we had going
into the (multi-month) research project we undertook before proposing this CEP.
These goals are necessarily value judgements, so we cannot expect that everyone
will agree that they are optimal.
So far you have not engaged with these goals to state any specific
disagreement. I have engaged with all of the trade-offs you imagined, and every
specific concern you have raised. Despite a month having elapsed and a great
deal of time spent answering your emails, this is the first confirmation I have
that you are dissatisfied with my responses to you.
The role of the CEP is to advertise a project, allowing people to register
their interest in collaborating, and for technical concerns to be stated in
advance. So far you have expressed no specific technical concerns that I have
not engaged with, and yet I have received no response to my engagements.
The role of the CEP is *not* to permit members of the community to dictate
their preferences on the proposers, or to declare that the CEP is inadequate
because it doesn’t meet their goals, or to demand additional work to explore
others’ preferred research avenues on the topic.
You have to do some of the work here, Jonathan.
If you have an alternative approach, I continue to ask you to propose it so we
may compare and contrast in a specific and technical manner. If you have any
specific technical concerns I exhort you to raise them, so we my discuss them.
If you dispute the goals, please make an argument as to why. If our goals are
irreconcilable, file another CEP.
From: Jonathan Ellis
Date: Wednesday, 6 October 2021 at 14:41
To: dev
Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
I've repeatedly explained why I'm unhappy: instead of starting with a
discussion of what API and tradeoffs we should make to get that, this CEP
starts with a protocol and asks us to figure out what API we can build with
it.
Of course by API I mean, what kinds of CQL and SQL operations we can
perform, with what kinds of ACID semantics and what kinds of performance,
not "Result perform(Transaction transaction)". And it's not simply SQL
syntax, either. I realize that this could sound a little vague, but that's
why I gave an example of the kind of analysis I'm talking about in my first
reply. Your responses have been to attempt to avoid the discussion
entirely ("the relevant goals are [mine]") or to declare it to be out of
scope.
The CEP process is intended to help get to alignment across the community
of PMC members, committers, and contributors on goals and outcomes before
starting in writing code, not simply to bless a completed design. That's
why we're going in circles here.
On Wed, Oct 6, 2021 at 2:12 AM bened...@apache.org
wrote:
> We have discussed the API at length in this thread. The API primarily
> involves the semantics of the transactions, as besides this the API of a
> transaction is simply:
>
> Result perform(Transaction transaction)
>
> As discussed in follow-up to that email, a prototype API is specified
> alongside the prototype protocol. I am unsure what more you want than this,
> or the above, or the prior semantic discussions.
>
> It seems clear that you’re unhappy with the proposal, but it remains
> ambiguous as to why. Your emails are terse, infrequent and unclear. My
> responses receive no follow up from you, even to clarify if I have answered
> your query. Sometime later I seem to be able to expect a new unrelated
> problem that you are unhappy about. You have not yet responded to even one
> of my repeated offers to hop on a call to hash out any of your concerns,
> even if only to decline.
>
> This does not feel like constructive and respectful engagement to me, and
> I am losing interest.
>
>
>
> From: Jonathan Ellis
> Date: Wednesday, 6 October 2021 at 00:02
> To: dev
> Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions
> I honestly can't understand the perspective that on the one hand, you're
> asking for approval of a specific protocol as part of the CEP, but on the
> other, you think discussion of the APIs this will enable is not warranted.
> Surely we need agreement on what APIs we're trying to build, before we
> discuss the protocols and architectures with which to build them.
>
> On Fri, Oct 1, 2021 at 9:34 AM bened...@apache.org
> wrote:
>
> > > The current document details thoroughly the protocol but in my view
> > lacks to illustrate what specific API, methods, modules will become
> > available to developers
> >
> > With respect to this, in my view this kind of detail is not warranted
> > within a CEP. Software development is an exploratory process with respect
> > to structure, and these decisions will be made as the CEP progresses. If
> > these need to be specified upfront, then the purpose of a CEP – seeking
> buy
> > in – is invalidated, because the work must be complete before you know
> the
> > answers.
> >
Re: Save CircleCI resources with optional test jobs
Hello all, The changes in CircleCI proposed in the previous messages are implemented in CASSANDRA-16882. They try to include the feedback from both the reviewers and the Slack discussion at https://the-asf.slack.com/archives/CK23JSY2K/p1631627458109000. The patch modifies the CircleCI config to have two pairs of j8/j11 workflows: * The javaX_pre-commit_tests workflows are meant to be used when a patch is definitively ready for final review and/or commit. They have a single approval step that starts all the basic tests, including unit tests, dtests, etc. Additionally, it has approval steps for those tests that are not generally required in every ticket, such as upgrade tests and the multiplexer. This pair of workflows is quite similar to what we currently have, and the main difference is that there is an approval step to start the build. * The javaX_separate_tests workflows are meant to be used in intermediate steps and special cases such as fixing flaky tests. All the jobs in these workflows have an individual approval step, so one can run any test job without wasting resources in the others. For example, it makes possible to repeatedly run a unit test without firing the entire JVM dtests. Here is an example of how the workflows would look like: https://app.circleci.com/pipelines/github/adelapena/cassandra?branch=16882-option-7-trunk-v04 Hopefully this approach would help us to save resources in intermediate development steps and special cases, while keeping the current concept of mandatory tests. If no one disagrees with this approach I'll commit the changes in a few days. On Fri, 27 Aug 2021 at 11:54, Andrés de la Peña wrote: > Hi, > > CASSANDRA-16882 has patches for any of the mentioned configurations aimed > to save CircleCI resources. > > There are CircleCI runs showing how each approach would look like, plus an > additional fourth option: > > 1. Make the entire workflow optional: > https://app.circleci.com/pipelines/github/adelapena/cassandra/800/workflows/9cb8ca7b-ab57-431e-a22b-643d61c92c29 > 2. Make all the test jobs optional: > https://app.circleci.com/pipelines/github/adelapena/cassandra/798/workflows/a859cfbc-fdf8-4468-beb9-b2ee17dc1ae3 > 3. Make all the mandatory test jobs depend on a single optional job: > https://app.circleci.com/pipelines/github/adelapena/cassandra/802/workflows/0372f5d6-d1f0-4f0e-91a3-aa75a2712bae > 4. Combine 2 and 3 to have approval jobs for both individual tests and the > grouped mandatory tests: > https://app.circleci.com/pipelines/github/adelapena/cassandra/803/workflows/08ae07d5-6a1e-4e5b-bc0c-32bdc9b9f190 > > I think that the fourth option gives us more flexibility, because it > allows us to start any combination of tests we want while it keeps the > concept of required tests. > > On Thu, 12 Aug 2021 at 17:47, Andrés de la Peña > wrote: > >> Hello all, >> >> The current CircleCI configuration automatically runs the unit tests, JVM >> dtests and cqhshlib tests. This is done by default for every commit or, >> with some configuration, for every push. >> >> Along the lifecycle of a ticket it is quite frequent to have multiple >> commits and pushes, all running these test jobs. I'd say that frequently it >> is not necessary to run the tests for some of those intermediate commits >> and pushes. For example, one can show proofs of concept, or have multiple >> rounds of review before actually running the tests. Running the tests for >> every change can produce an unnecessary expense of CircleCI resources. >> >> I think we could make running those tests optional, as well as clearly >> specifying in the documentation what are the tests runs that are mandatory >> before actually committing. We could do this in different ways: >> >> 1. Make the entire CircleCI workflow optional, so the build job requires >> manual approval. Once the build is approved the mandatory test jobs would >> be run without any further approval, exactly as it's currently done. >> >> 2. Make all the test jobs optional, so every test job requires manual >> approval, and the documentation specifies which tests are mandatory in the >> final steps of a ticket. >> >> 3. Make all the mandatory test jobs depend on a single optional job, so >> we have a single button to optionally run all the mandatory tests. >> >> I think any of these changes, or a combination of them, would >> significantly reduce the usage of resources without making things less >> tested. The only downside I can think of is that we would need some >> additional clicks on the CircleCI GUI. What do you think? >> >
Re: [DISCUSS] CEP-15: General Purpose Transactions
On Wed, Oct 6, 2021 at 9:21 AM bened...@apache.org wrote: > The goals of the CEP are stated clearly, and these were the goals we had > going into the (multi-month) research project we undertook before proposing > this CEP. These goals are necessarily value judgements, so we cannot expect > that everyone will agree that they are optimal. > Right, so I'm saying that this is exactly the most important thing to get consensus on, and creating a CEP for a protocol to achieve goals that you have not discussed with the community is the CEP equivalent of dropping a patch on Jira without discussing its goals either. That's why our conversations haven't gone anywhere, because I keep saying "we need discuss the goals and tradeoffs", and I'll give an example of what I mean, and you keep addressing the examples (sometimes very shallowly, "it would be possible to X" or "Y could be done as an optimization") while ignoring the request to open a discussion around the big picture.
Re: [DISCUSS] CEP-15: General Purpose Transactions
The problem with dropping a patch on Jira is that there is no opportunity to point out problems, either with the fundamental approach or with the specific implementation. So please point out some problems I can engage with! From: Jonathan Ellis Date: Wednesday, 6 October 2021 at 15:48 To: dev Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions On Wed, Oct 6, 2021 at 9:21 AM bened...@apache.org wrote: > The goals of the CEP are stated clearly, and these were the goals we had > going into the (multi-month) research project we undertook before proposing > this CEP. These goals are necessarily value judgements, so we cannot expect > that everyone will agree that they are optimal. > Right, so I'm saying that this is exactly the most important thing to get consensus on, and creating a CEP for a protocol to achieve goals that you have not discussed with the community is the CEP equivalent of dropping a patch on Jira without discussing its goals either. That's why our conversations haven't gone anywhere, because I keep saying "we need discuss the goals and tradeoffs", and I'll give an example of what I mean, and you keep addressing the examples (sometimes very shallowly, "it would be possible to X" or "Y could be done as an optimization") while ignoring the request to open a discussion around the big picture.
Re: [DISCUSS] CEP-15: General Purpose Transactions
The problem that I keep pointing out is that you've created this CEP for Accord without first getting consensus that the goals and the tradeoffs it makes to achieve those goals (and that it will impose on future work around transactions) are the right ones for Cassandra long term. At this point I'm done repeating myself. For the convenience of anyone following this thread intermittently, I'll quote my first reply on this thread to illustrate the kind of discussion I'd like to have. - The whitepaper here is a good description of the consensus algorithm itself as well as its robustness and stability characteristics, and its comparison with other state-of-the-art consensus algorithms is very useful. In the context of Cassandra, where a consensus algorithm is only part of what will be implemented, I'd like to see a more complete evaluation of the transactional side of things as well, including performance characteristics as well as the types of transactions that can be supported and at least a general idea of what it would look like applied to Cassandra. This will allow the PMC to make a more informed decision about what tradeoffs are best for the entire long-term project of first supplementing and ultimately replacing LWT. (Allowing users to mix LWT and AP Cassandra operations against the same rows was probably a mistake, so in contrast with LWT we’re not looking for something fast enough for occasional use but rather something within a reasonable factor of AP operations, appropriate to being the only way to interact with tables declared as such.) Besides Accord, this should cover - Calvin and FaunaDB - A Spanner derivative (no opinion on whether that should be Cockroach or Yugabyte, I don’t think it’s necessary to cover both) - A 2PC implementation (the Accord paper mentions DynamoDB but I suspect there is more public information about MongoDB) - RAMP Here’s an example of what I mean: =Calvin= Approach: global consensus (Paxos in Calvin, Raft in FaunaDB) to order transactions, then replicas execute the transactions independently with no further coordination. No SPOF. Transactions are batched by each sequencer to keep this from becoming a bottleneck. Performance: Calvin paper (published 2012) reports linear scaling of TPC-C New Order up to 500,000 transactions/s on 100 machines (EC2 XL machines with 7GB ram and 8 virtual cores). Note that TPC-C New Order is composed of four reads and four writes, so this is effectively 2M reads and 2M writes as we normally measure them in C*. Calvin supports mixed read/write transactions, but because the transaction execution logic requires knowing all partition keys in advance to ensure that all replicas can reproduce the same results with no coordination, reads against non-PK predicates must be done ahead of time (transparently, by the server) to determine the set of keys, and this must be retried if the set of rows affected is updated before the actual transaction executes. Batching and global consensus adds latency -- 100ms in the Calvin paper and apparently about 50ms in FaunaDB. Glass half full: all transactions (including multi-partition updates) are equally performant in Calvin since the coordination is handled up front in the sequencing step. Glass half empty: even single-row reads and writes have to pay the full coordination cost. Fauna has optimized this away for reads but I am not aware of a description of how they changed the design to allow this. Functionality and limitations: since the entire transaction must be known in advance to allow coordination-less execution at the replicas, Calvin cannot support interactive transactions at all. FaunaDB mitigates this by allowing server-side logic to be included, but a Calvin approach will never be able to offer SQL compatibility. Guarantees: Calvin transactions are strictly serializable. There is no additional complexity or performance hit to generalizing to multiple regions, apart from the speed of light. And since Calvin is already paying a batching latency penalty, this is less painful than for other systems. Application to Cassandra: B-. Distributed transactions are handled by the sequencing and scheduling layers, which are leaderless, and Calvin’s requirements for the storage layer are easily met by C*. But Calvin also requires a global consensus protocol and LWT is almost certainly not sufficiently performant, so this would require ZK or etcd (reasonable for a library approach but not for replacing LWT in C* itself), or an implementation of Accord. I don’t believe Calvin would require additional table-level metadata in Cassandra. On Wed, Oct 6, 2021 at 9:53 AM bened...@apache.org wrote: > The problem with dropping a patch on Jira is that there is no opportunity > to point out problems, either with the fundamental approach or with the > specific implementation. So please point out some problems I can engage > with! > > > From: Jonathan Ellis > Date: Wednesday, 6 October 2021 at
Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
On Wed, Oct 6, 2021 at 8:48 AM bened...@apache.org wrote: > That’s probably not a good reason here, and I agree that overloading > consistency level feels wrong. I hope we will retire user-provided > consistency levels over the coming year or two, which is another good > reason not to begin enhancing it with new meanings. I would love to see CLs simplified. Even without user-provided CL we almost certainly have too many. Providing a migration path is the hard part.
Re: [DISCUSS] CEP-15: General Purpose Transactions
Jonathan, This work will only determine Cassandra’s future if no other contributors choose to take a different route in future. If in future the community decides this work is incompatible with its direction, it remains in the community’s power to remove the facility, or to make it optional. OSS is a living thing, and this CEP will shape the future of community only by virtue of the work that I and others will do. You are equally capable of investing this time and effort. Today, this is the only CEP of the kind on offer. If another competing proposal were to be made, we could either work to reconcile them, or to ensure they may co-exist. You cannot, however, expect to impose your _goals_ on the work that I and others will undertake. That is not how the community works. Since we are going around in circles, I propose a simple majority vote to establish if the community endorses the stated goals of the CEP. From: Jonathan Ellis Date: Wednesday, 6 October 2021 at 16:05 To: dev Subject: Re: [DISCUSS] CEP-15: General Purpose Transactions The problem that I keep pointing out is that you've created this CEP for Accord without first getting consensus that the goals and the tradeoffs it makes to achieve those goals (and that it will impose on future work around transactions) are the right ones for Cassandra long term. At this point I'm done repeating myself. For the convenience of anyone following this thread intermittently, I'll quote my first reply on this thread to illustrate the kind of discussion I'd like to have. - The whitepaper here is a good description of the consensus algorithm itself as well as its robustness and stability characteristics, and its comparison with other state-of-the-art consensus algorithms is very useful. In the context of Cassandra, where a consensus algorithm is only part of what will be implemented, I'd like to see a more complete evaluation of the transactional side of things as well, including performance characteristics as well as the types of transactions that can be supported and at least a general idea of what it would look like applied to Cassandra. This will allow the PMC to make a more informed decision about what tradeoffs are best for the entire long-term project of first supplementing and ultimately replacing LWT. (Allowing users to mix LWT and AP Cassandra operations against the same rows was probably a mistake, so in contrast with LWT we’re not looking for something fast enough for occasional use but rather something within a reasonable factor of AP operations, appropriate to being the only way to interact with tables declared as such.) Besides Accord, this should cover - Calvin and FaunaDB - A Spanner derivative (no opinion on whether that should be Cockroach or Yugabyte, I don’t think it’s necessary to cover both) - A 2PC implementation (the Accord paper mentions DynamoDB but I suspect there is more public information about MongoDB) - RAMP Here’s an example of what I mean: =Calvin= Approach: global consensus (Paxos in Calvin, Raft in FaunaDB) to order transactions, then replicas execute the transactions independently with no further coordination. No SPOF. Transactions are batched by each sequencer to keep this from becoming a bottleneck. Performance: Calvin paper (published 2012) reports linear scaling of TPC-C New Order up to 500,000 transactions/s on 100 machines (EC2 XL machines with 7GB ram and 8 virtual cores). Note that TPC-C New Order is composed of four reads and four writes, so this is effectively 2M reads and 2M writes as we normally measure them in C*. Calvin supports mixed read/write transactions, but because the transaction execution logic requires knowing all partition keys in advance to ensure that all replicas can reproduce the same results with no coordination, reads against non-PK predicates must be done ahead of time (transparently, by the server) to determine the set of keys, and this must be retried if the set of rows affected is updated before the actual transaction executes. Batching and global consensus adds latency -- 100ms in the Calvin paper and apparently about 50ms in FaunaDB. Glass half full: all transactions (including multi-partition updates) are equally performant in Calvin since the coordination is handled up front in the sequencing step. Glass half empty: even single-row reads and writes have to pay the full coordination cost. Fauna has optimized this away for reads but I am not aware of a description of how they changed the design to allow this. Functionality and limitations: since the entire transaction must be known in advance to allow coordination-less execution at the replicas, Calvin cannot support interactive transactions at all. FaunaDB mitigates this by allowing server-side logic to be included, but a Calvin approach will never be able to offer SQL compatibility. Guarantees: Calvin transactions are strictly serializable. There is no additional complexity or performance hit to gene
Re: [DISCUSS] CEP-15: General Purpose Transactions
Hi folks,Thanks for discussion on this proposal, and also to Benedict who’s been fielding questions on the list!I’d like to restate the goals and problem statement captured by this proposal and frame context.Today, lightweight transactions limit users to transacting over a single partition. This unit of atomicity has a very low upper limit in terms of the amount of data that can be CAS’d over; and doing so leads many to design contorted data models to cram different types of data into one partition for the purposes of being able to CAS over it. We propose that Cassandra can and should be extended to remove this limit, enabling users to issue one-shot transactions that CAS over multiple keys – including CAS batches, which may modify multiple keys.To enable this, the CEP authors have designed a novel, leaderless paxos-based protocol unique to Cassandra, offered a proof of its correctness, a whitepaper outlining it in detail, along with a prototype implementation to incubate development, and integrated it with Maelstrom from jepsen.io to validate linearizability as more specific test infrastructure is developed. This rigor is remarkable, and I’m thrilled to see such a degree of investment in the area.Even users who do not require the capability to transact across partition boundaries will benefit. The protocol reduces message/WAN round-trips by 4x on writes (4 → 1) and 2x on reads (2 → 1) in the common case against today’s baseline. These latency improvements coupled with the enhanced flexibility of what can be transacted over in Cassandra enable new classes of applications to use the database.In particular, 1xRTT read/write transactions across partitions enable Cassandra to be thought of not just as a strongly consistent database, but even a transactional database - a mode many may even prefer to use by default. Given this capability, Apache Cassandra has an opportunity to become one of – or perhaps the only – database in the industry that can store multiple petabytes of data in a single database; replicate it across many regions; and allow users to transact over any subset of it. These are capabilities that can be met by no other system I’m aware of on the market. Dynamo’s transactions are single-DC. Google Cloud BigTable does not support transactions. Spanner, Aurora, CloudSQL, and RDS have far lower scalability limits or require specialized hardware, etc.This is an incredible opportunity for Apache Cassandra - to surpass the scalability and transactional capability of some of the most advanced systems in our industry - and to do so in open source, where anyone can download and deploy the software to achieve this without cost; and for students and researchers to learn from and build upon as well (a team from UT-Austin has already reached out to this effect).As Benedict and Blake noted, the scope of what’s captured in this proposal is also not terminal. While the first implementation may extend today’s CAS semantics to multiple partitions with lower latency, the foundation is suitable to build interactive transactions as well — which would be remarkable and is something that I hadn’t considered myself at the onset of this project.To that end, the CEP proposes the protocol, offers a validated implementation, and the initial capability of extending today’s single-partition transactions to multi-partition; while providing the flexibility to build upon this work further.A simple example of what becomes possible when this work lands and is integrated might be:––– BEGIN BATCHUPDATE tbl1 SET value1 = newValue1 WHERE partitionKey = k1UPDATE tbl2 SET value2 = newValue2 WHERE partitionKey = k2 AND conditionValue = someConditionAPPLY BATCH –––I understand that this query is present in the CEP and my intent isn’t to recommend that folks reread it if they’ve given a careful reading already. But I do think it’s important to elaborate upon what becomes possible when this query can be issued.Users of Cassandra who have designed data models that cram many types of data into a single partition for the purposes of atomicity no longer need to. They can design their applications with appropriate schemas that wouldn’t leave Codd holding his nose. They’re no longer pushed into antipatterns that result in these partitions becoming huge and potentially unreadable. Cassandra doesn’t become fully relational in this CEP - but it becomes possible and even easy to design applications that transact across tables that mimic a large amount of relational functionality. And for users who are content to transact over a single table, they’ll find those transactions become up to 4x faster today due to the protocol’s reduction in round-trips. The library’s loose coupling to Apache Cassandra and ability to be incubated out-of-tree also enables other applications to take advantage of the protocol and is a nice step toward bringing modularity to the project. There are a lot of good things happ
Re: [DISCUSS] Cleaning up docs, completing CASSANDRA-16763
Hey Lorina, First of all - thank you so much for all the work done by you and the rest of the people! The website and the docs are our front door as a project! +1 on your proposal. My understanding is we need 1)+5) and then everything else will be able to roll out and more people will be able to join the efforts so we can knock out 2) which seems the biggest work here, did I get it correct? My only comment is about the tickets we will have to open. I can suggest we don’t do 1:1 ticket for every small backport ticket/change but 1:1 for bigger bodies of work and 1:many where we see we can combine a few smaller changes so we don’t deal with too many tickets. Does this sound reasonable? Is there a different suggestion or plan? Thank you one more time. I will be happy to help with what I can do in order to bring this to the finish line. I am sure others will do too even with a ticket or two :-) In OSS every single contribution matter, right? Best regards, Ekaterina On Wed, 6 Oct 2021 at 8:22, Benjamin Lerer wrote: > Thanks Lorina for all your work. > > +1 Your proposal makes sense to me. > > Le mer. 6 oct. 2021 à 00:34, Lorina Poland a écrit : > > > This is a discussion about how to tackle getting the docs “fixed”. > > > > As many of you know, I started months ago to convert the Apache Cassandra > > in-tree docs > > from reStructedText (rST)to AsciiDoc. [1] > > The conversion required both the docs source files to be converted, but > > also the cassandra-website > > source to be updated, to build the docs from AsciiDoc.[2] You all have > seen > > the results of that > > conversion + the beautiful new design work accomplished. > > When Apache Cassandra 4.0 was ready to GA, we used my private repo > > (polandll/cassandra) to build the docs for > > publication. (The new cassandra-website procedure allows for any repo to > be > > used to build.) > > Due to a series of interferences with virtually all the people on the > > project > > (myself, Anthony Grasso, Mick Semb Wever, Paul Lau) in the time leading > up > > to the GA or right after, > > we have never gotten my repo work committed and merged to the official > > source (apache/cassandra). > > So, here is the proposal for a plan of action: > > > > (1) Anthony and Lorina get the 4.0/trunk and 3.11 branches that Lorina > > worked on for the last 18 months > > ready for merge from polandll/cassandra -> apache/cassandra. > > (2) There are changes that were made in the last 18 months to docs (in > the > > current rST docs) that need > > to be backported to the new adoc docs. We can use the commit history to > > hunt down those changes and make > > tickets for each of them. Those tickets can be listed under an umbrella > > ticket. > > (3) There are tickets that already exist that I asked people to wait on > > merging during the conversion. > > Those tickets also need to be completed. > > (4) There are a few tickets for PRs people submitted to my private repo > (oh > > my!) that should be completed > > again in the official repo. > > (5) I will write a “how to contribute to docs” that gives people a > rundown > > of how to write AsciiDoc. > > > > We would like to merge the docs in their current state, step (1), then > make > > the backports, rather than make the > > backports then merge to the apache/cassandra repo. Main reason for this > > order is that, at least the docs > > and website could be built from official repos once that is done. Until > the > > adoc conversion is merged, > > the docs and website can only be built from my personal repo, which is a > > sad situation. > > > > Lastly, just to clarify the work we want to merge. I modified the trunk > for > > 4.0 and made all the changes > > required. (750+ files). Then, rather than modify the 3.11 branch, I wrote > > trunk to 3.11 and > > removed the “What’s new” folder (called /new, unimaginatively). I had > > planned to then go back and > > incorporate the "What’s new" material into the appropriate places in the > > 4.0 docs, because, in short order, > > those changes are no longer what’s new. > > > > [1] > > > > > https://lists.apache.org/thread.html/r42802f86d7893c42b5091fe7f7d4b048a63cbe0fd11fadcd120596e3%40%3Cdev.cassandra.apache.org%3E > > [2] > > > > > https://lists.apache.org/thread.html/r961c52f58a42a3b2cae7299244a525311283cd2758d0201f8b0feb83%40%3Cdev.cassandra.apache.org%3E > > >
Re: [DISCUSS] CASSANDRA-17024: Artificial Latency Injection
> On Oct 6, 2021, at 8:07 AM, Jonathan Ellis wrote: > > I would love to see CLs simplified. Even without user-provided CL we > almost certainly have too many. Providing a migration path is the hard > part. +1 on deprecating consistency levels. Migration path is easy for most use-cases. Some niche users may have a hard time moving away from them. Dinesh - To unsubscribe, e-mail: dev-unsubscr...@cassandra.apache.org For additional commands, e-mail: dev-h...@cassandra.apache.org
