> I think the primary argument *against* Accord is that the syntax isn't > expressive enough to be able to address multiple conditions in MVs. For each > field that's updated, you'll need to know if you want to add that update into > the transaction, and you'd need to check if it was modified. Currently > Accord only support a single conditional on the entire transaction.
What Blake said, we limited the CQL API for the first drop to get feedback on things (such as what the default result return be). But internal logic is free to do w/e it wants, so if you need If (isUpdated(field1) INSERT If (isUpdated(field2)) INSERT If (isUpdated(field4) INSERT Nothing should get in the way, this is internal so we don’t have to worry about the public API. > On May 7, 2025, at 9:31 AM, Blake Eggleston <bl...@ultrablake.com> wrote: > > > Yes, you need to read the original row before the transaction begins in > > order to get the initial state, but could be done at local one by the > > coordinator, reading itself. The performance overhead of an additional, > > local one read should be significantly less than a Paxos transaction that > > has to do additional round trips. > > Assuming the trick of overloading the paxos propose phase with a view update > mutation doesn’t have correctness edge cases, you may be able to get away > with doing something similar at the Accord apply phase, eliminating the need > for 2 operations. > > > I think the primary argument *against* Accord is that the syntax isn't > > expressive enough to be able to address multiple conditions in MVs. For > > each field that's updated, you'll need to know if you want to add that > > update into the transaction, and you'd need to check if it was modified. > > Currently Accord only support a single conditional on the entire > > transaction. > > That's a limitation of the CQL syntax, but not of accord itself. There's > nothing preventing internal features from providing their own Txn > implementation to be coordinated. > > On Wed, May 7, 2025, at 9:00 AM, Jon Haddad wrote: >> Glad to see folks are looking to improve MVs. Definitely one of the areas >> we need some attention paid to. >> >> Do you have a patch already for this? We haven't had a discussion yet about >> winding down new development in trunk but IMO we should probably stop >> merging big things in soon and focus on getting the release out. >> >> Since you're planning on making this opt-in, I think it might be better to >> leverage accord transactions. The code should be quite a bit simpler on the >> write path. Accord should require fewer round trips and work >> *significantly* better when there's multiple data centers. >> >> > While this design enables atomic updates across base tables and MVs, it is >> > inefficient—even in the common (happy path) case—because it involves >> > reading the base table row twice: once before the transaction begins and >> > again during the transaction itself. This introduces unnecessary overhead. >> Yes, you need to read the original row before the transaction begins in >> order to get the initial state, but could be done at local one by the >> coordinator, reading itself. The performance overhead of an additional, >> local one read should be significantly less than a Paxos transaction that >> has to do additional round trips. So at this point, I'm not convinced that >> performance of Accord transactions will be any more than Paxos ones, in fact >> I think it's probably the opposite. >> >> From a reliability perspective, you've made a good point that Accord is new, >> but you're also proposing this be opt-in. I think if you're going to make >> it opt-in anyways, we might as well go with something that isn't going to be >> considered tech debt as soon as it's merged. >> >> I think the primary argument *against* Accord is that the syntax isn't >> expressive enough to be able to address multiple conditions in MVs. For >> each field that's updated, you'll need to know if you want to add that >> update into the transaction, and you'd need to check if it was modified. >> Currently Accord only support a single conditional on the entire transaction. >> >> From a project perspective, I'd *much* rather see improvements to the >> expressiveness of transactions and gives us a long term solution, than >> something that we will immediately want to migrate off of after a single >> version. >> >> Curious what others think though. I'm +1 on the spirit of getting MVs to a >> stable point, but not convinced this is the best approach. >> >> Jon >> >> >> On Wed, May 7, 2025 at 1:45 AM guo Maxwell <cclive1...@gmail.com >> <mailto:cclive1...@gmail.com>> wrote: >> After thinking about it, if you want to use accord for synchronization in >> the future, you need to modify the base table attribute " transactional_mode >> = 'full' ". >> If the user's base table does not want to use accord, do you plan to force >> the modification of this attribute? >> >> Runtian Liu <curly...@gmail.com <mailto:curly...@gmail.com>> 于2025年5月7日周三 >> 12:08写道： >> Thanks for the questions. A few clarifications: >> >> Performance impact & opt-in model: The new MV synchronization mechanism is >> fully opt-in. We understand that LWT-backed writes may introduce performance >> overhead, so users who prefer higher throughput over strict consistency can >> continue using the existing MV implementation. The new strict consistency >> mode can be toggled via a table-level option. >> >> Support for both implementations: Even if this CEP is accepted, the current >> MV behavior will remain available. Users will have the flexibility to enable >> or disable the new mode as needed. >> >> Repair frequency: MV inconsistency detection and repair is integrated with >> Cassandra’s existing repair framework. It can be triggered manually via >> nodetool or scheduled using the auto-repair infrastructure (per CEP-37), >> allowing operators to control how frequently repairs run. >> >> >> On Tue, May 6, 2025 at 7:09 PM guo Maxwell <cclive1...@gmail.com >> <mailto:cclive1...@gmail.com>> wrote: >> If the entire write operation involves additional LWTs to change the MV, it >> is uncertain whether users can accept the performance loss of such write >> operations. >> >> If this CEP is finally accepted, I think users should at least be given the >> choice of whether to use the old method or the new method, because after >> all, some users pursue performance rather than strict data consistency（we >> can provide the ability of disabling or enabling the new mv mv >> synchronization mechanism）. >> >> Another question : What is the frequency of inconsistency detection and >> repair for mv and base table ? >> >> Runtian Liu <curly...@gmail.com <mailto:curly...@gmail.com>> 于2025年5月7日周三 >> 06:51写道： >> Hi everyone, >> >> We’d like to propose a new Cassandra Enhancement Proposal: CEP-48: >> First-Class Materialized View Support >> <https://cwiki.apache.org/confluence/display/CASSANDRA/CEP-48%3A+First-Class+Materialized+View+Support>. >> >> This CEP focuses on addressing the long-standing consistency issues in the >> current Materialized View (MV) implementation by introducing a new >> architecture that keeps base tables and MVs reliably in sync. It also adds a >> new validation and repair type to Cassandra’s repair process to support MV >> repair based on the base table. The goal is to make MV a first-class, >> production-ready feature that users can depend on—without relying on >> external reconciliation tools or custom workarounds. >> >> We’d really appreciate your feedback—please keep the discussion on this >> mailing list thread. >> >> >> Thanks, >> Runtian >> >
