You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Matthias Broecheler (JIRA)" <ji...@apache.org> on 2016/06/21 06:16:58 UTC

[jira] [Commented] (CASSANDRA-9928) Add Support for multiple non-primary key columns in Materialized View primary keys

    [ https://issues.apache.org/jira/browse/CASSANDRA-9928?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15341188#comment-15341188 ] 

Matthias Broecheler commented on CASSANDRA-9928:
------------------------------------------------

Requiring that all non-PK columns that are indexed be updated at the same time is too much of a limitation and will be really hard for users to understand imho. 

Instead, I would propose that we introduce a rate-change limit on the columns that participate in an MV. If we can guarantee that there is a limit on the number of changes to those columns than we can limit the number of distinct state permutations that may need to be considered in the scenarios above. In those cases, we would simply enumerate them and then delete all possible old MV states.This sounds expensive but it would only be expensive when change happen in fast succession or under extraordinary operational conditions - i.e. the cost should amortize well.

As for the rate limit, it seems that this would be a rather arbitrary limitation but if somebody changes their MV columns in rapid succession then they are pursuing an anti-pattern and throwing an exception would be a better response that deteriorating system performance.

> Add Support for multiple non-primary key columns in Materialized View primary keys
> ----------------------------------------------------------------------------------
>
>                 Key: CASSANDRA-9928
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-9928
>             Project: Cassandra
>          Issue Type: Improvement
>            Reporter: T Jake Luciani
>              Labels: materializedviews
>             Fix For: 3.x
>
>
> Currently we don't allow > 1 non primary key from the base table in a MV primary key.  We should remove this restriction assuming we continue filtering out nulls.  With allowing nulls in the MV columns there are a lot of multiplicative implications we need to think through.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)