You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Carl Yeksigian (JIRA)" <ji...@apache.org> on 2015/08/03 17:36:04 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=14651989#comment-14651989 ] 

Carl Yeksigian commented on CASSANDRA-9928:
-------------------------------------------

[~benedict] brought up some potential issues in [a comment|https://issues.apache.org/jira/browse/CASSANDRA-6477#MultipleColumns] on CASSANDRA-6477:
{quote}
As far as multiple columns are concerned: I think we may need to go back to the drawing board there. It's actually really easy to demonstrate the cluster getting into broken states. Say you have three columns, A B C, and you send three competing updates a b c to their respective columns; previously all held the value _. If they arrive in different orders on each base-replica we can end up with 6 different MV states around the cluster. If any base replica dies, you don't know which of those 6 intermediate states were taken (and probably replicated) by its MV replicas. This problem grows exponentially as you add "competing" updates (which, given split brain, can compete over arbitrarily long intervals).

This is where my concern about a "single (base) node" dependency comes in, but after consideration it's clear that with a single column this problem is avoided because it's never ambiguous what the old state was. If you encounter a mutation that is shadowed by your current data, you can always issue a delete for the correct prior state. With multiple columns that is no longer possible.

I'm pretty sure the presence of multiple columns introduces other issues with each of the other moving parts.
{quote}

When we implement this feature, we should make sure to also add jepsen tests for the possible problems.

> 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.0 beta 1
>
>
> 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)