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