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

> what we're trying to achieve here is comparing two massive unordered sets. They are not two unordered sets, but rather two sets ordered by different keys. This means that when building Merkle trees for the base table and the materialized view (MV), we need to use different strategies to ensure t

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

> I think in order to address this, the view should be propagated to the base > replicas *after* it's accepted by all or a majority of base replicas. This is > where I think mutation tracking could probably help. Yeah, the idea of "don't reflect in the MV until you hit the CL the user requested

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

> I think requiring a rebuild is a deal breaker for most teams. In most instances it would be having to also expand the cluster to handle the additional disk requirements. It turns an inconsistency problem into a major operational headache that can take weeks to resolve. Agreed. The rebuild wou

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

I think requiring a rebuild is a deal breaker for most teams. In most instances it would be having to also expand the cluster to handle the additional disk requirements. It turns an inconsistency problem into a major operational headache that can take weeks to resolve. On Thu, May 15, 2025 a

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

> There's bi-directional entropy issues with MV's - either orphaned view data or missing view data; that's why you kind of need a "bi-directional ETL" to make sure the 2 agree with each other. While normal repair would resolve the "missing data in MV" case, it wouldn't resolve the "data in MV that'

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

There's bi-directional entropy issues with MV's - either orphaned view data or missing view data; that's why you kind of need a "bi-directional ETL" to make sure the 2 agree with each other. While normal repair would resolve the "missing data in MV" case, it wouldn't resolve the "data in MV that

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

Maybe, I’m not really familiar enough with how “classic” MV repair works to say. You can’t mix normal repair and mutation reconciliation in the current incarnation of mutation tracking though, so I wouldn’t assume it would work with MVs. On Wed, May 14, 2025, at 11:29 AM, Jon Haddad wrote: > In

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

In the case of bitrot / losing an SSTable, wouldn't a normal repair (just the MV against the other nodes) resolve the issue? On Wed, May 14, 2025 at 11:27 AM Blake Eggleston wrote: > Mutation tracking is definitely an approach you could take for MVs. > Mutation reconciliation could be extended t

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

Mutation tracking is definitely an approach you could take for MVs. Mutation reconciliation could be extended to ensure all changes have been replicated to the views. When a base table received a mutation w/ an id it would generate a view update. If you block marking a given mutation id as recon

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

I was thinking along the lines of mutation tracking too, but I have to admit I haven't spent much time on reading through it, it's probably time I did. I'd read up on it, thanks for bringing it up. One thing to consider is that 5TB is not particularly dense anymore, in the world of Cassandra 5+.

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

I don't see mutation tracking [1] mentioned in this thread or in the CEP-48 description. Not sure this would fit into the scope of this initial CEP, but I have a feeling that mutation tracking could be potentially helpful to reconcile base tables and views ? For example, when both base and view up

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

> - The first thing I notice is that we're talking about repairing the entire table across the entire cluster all in one go. It's been a *long* time since I tried to do a full repair of an entire table without using sub-ranges. Is anyone here even doing that with clusters of non-trivial size? Ho

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

Putting this another way - what we're trying to achieve here is comparing two massive unordered sets. I believe the worst case is a O(N^2) complexity, and N can be in the billions. I really think we need a completely different approach here than how repair currently works. For me to be a +1 on t

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

I've got several concerns around this repair process. - The first thing I notice is that we're talking about repairing the entire table across the entire cluster all in one go. It's been a *long* time since I tried to do a full repair of an entire table without using sub-ranges. Is anyone here e

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

> 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? We are going to support Paxos V2. The CEP is not clear on

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

>Like something doesn't add up here because if it always includes the base table's primary key columns that means The requirement for materialized views (MVs) to include the base table's primary key appears to be primarily a syntactic constraint specific to Apache Cassandra. For instance, in Dynam

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

> Or compaction hasn’t made a mistake, or cell merge reconciliation hasn’t made a mistake, or volume bitrot hasn’t caused you to lose a file. > Repair isnt’ just about “have all transaction commits landed”. It’s “is the data correct N days after it’s written”. Don't forget about restoring from a b

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

> Like something doesn't add up here because if it always includes the base > table's primary key columns that means they could be storage attached by just > forbidding additional columns and there doesn't seem to be much utility in > including additional columns in the primary key? You can re-

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

> On May 12, 2025, at 8:10 AM, Ariel Weisberg wrote: > > Hi, > > I think it's worth taking a step back and looking at the current MV > restrictions which are pretty onerous. > > A view must have a primary key and that primary key must conform to the > following restrictions: > it must conta

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

Hi, I think it's worth taking a step back and looking at the current MV restrictions which are pretty onerous. A view must have a primary key and that primary key must conform to the following restrictions: • it must contain all the primary key columns of the base table. This ensures that eve

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

> This makes me really, really concerned with how it scales, and how likely it > is to be able to schedule automatically without blowing up. It seems to me that resource-aware throttling would be the solution here, or from a more primitive case, just hard bounding threadpool size, throughput ra

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