Hi, Great to see MVs getting some attention and it's a good time to start addressing their shortcomings.
Looking at the details of the CEP it seems to describe Paxos as PaxosV1, but PaxosV2 works slightly differently (it can read during the prepare phase). I assume that supporting Paxos means supporting both V1 and V2 for materialized views? As has been mentioned Accord doesn't have many restrictions on what you can do logically in a transaction. The only significant restrictions are that you must know the keys that are going to be read/written to when the transaction starts (known in this case) and you can only read once, process the result of the read, and then generate a single set of writes to apply. Here are some docs explaining how CQL is implemented on Accord https://github.com/aweisberg/cassandra-website/blob/20637/content/doc/trunk/cassandra/architecture/cql-on-accord.html Why mandate `LOCAL_QUORUM` instead of using the consistency level requested by the application? If they want to use `LOCAL_QUORUM` they can always request it. Using a transaction system as a better batch log for a key seems like a pretty reasonable way to make reads/writes for materialized views safer. A really good implementation of this would overlap the MV read with the read from the transaction system for unfinished updates and then discard or augment it if the MV read is incomplete. Accord will do this for you automatically just by virtue of supporting multi-key transactions. I am *big* fan of getting repair really working with MVs. It does seem problematic that the number of merkle trees will be equal to the number of ranges in the cluster and repair of MVs would become an all node operation. How would down nodes be handled and how many nodes would simultaneously working to validate a given base table range at once? How many base table ranges could simultaneously be repairing MVs? If a row containing a column that creates an MV partition is deleted, and the MV isn't updated, then how does the merkle tree approach propagate the deletion to the MV? The CEP says that anti-compaction would remove extra rows, but I am not clear on how that works. When is anti-compaction performed in the repair process and what is/isn't included in the outputs? Thanks, Ariel On Tue, May 6, 2025, at 6:51 PM, Runtian Liu wrote: > 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 >
