Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I’ve added a new section on isolation and consistency . In our current design, materialized-view tables stay eventually consistent,

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> The MV repair tool in Cassandra is intended to address inconsistencies that > may occur in materialized views due to various factors. This component is the > most complex and demanding part of the development effort, representing > roughly 70% of the overall work. > but I am very concerned ab

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> On May 9, 2025, at 12:59 PM, Ariel Weisberg wrote: > > > 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

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I should add that I’m in favour of this proposal in principle, and support the proposal to utilise Paxos.On 9 May 2025, at 08:21, Benedict Elliott Smith wrote:I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol details.

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

I’d also like to explore a bit further the isolation guarantees we’re promising with "Strict Consistency Mode” - and the protocol details. By strict, do we mean linearizable? Either way, we should state the guarantees explicitly so we can evaluate whether the protocol can meet them. Also, if the

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Setting aside the paxos vs accord conversation (though admittedly my first question would have been “why not accord”), I’m curious from folks who have thought about this how you’re thinking about correctness of repairI ask because I have seen far more data resurrection cases than I have lost write

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Here’s my perspective: #1 Accord vs. LWT round trips Based on the insights shared by the Accord experts, it appears that implementing MV using Accord can achieve a comparable number of round trips as the LWT solution proposed in CEP-48. Additionally, it seems that the number of WAN RTTs might be

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

Based on David and Blake’s responses, it sounds like we don’t need to block on anything. I realize you may be making a broader point, but in this instance it sounds like there’s nothing here preventing an accord based MV implementation. Now that i understand more about how it would be done, it als

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> IMHO, focus should be on accord-based MVs. Even if that means it's blocked > on first adding support for multiple conditions. > Strongly disagree here. We should develop features to be as loosely coupled w/one another as possible w/an eye towards future compatibility and leverage but not blo

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> 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. > IMHO, focus should be on accord-based MVs. Even if that means it's blocked on first adding support for multiple conditions.

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

> 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

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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 gett

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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 于2025年5月7日周

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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 co

Re: [DISCUSS] CEP-48: First-Class Materialized View Support

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

[DISCUSS] CEP-48: First-Class Materialized View Support

Hi everyone, We’d like to propose a new Cassandra Enhancement Proposal: CEP-48: First-Class Materialized View Support . This CEP focuses on addressing the long-standing consistency issues in th