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