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