> 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> 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> 于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> 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> 于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 >>>>>
