cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Sylvain Lebresne (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
Date Tue, 14 Jul 2015 15:08:09 GMT

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

Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------

bq. Because one isn't implicitly a hot spot

Ok, gotcha, MV table where the partition key is a single column that is not a PK from the
base table will create implicit hot spots. I'm personally happy to disallow that case. That's
still a very specific case: MV tables with multiple partition key columns where one of them
is a PK in the base table (but not all of them are) don't have this problem, so the the underlying
question of how we support that is still open.

bq. we would have to insert new NULL values after a TTL expired

Good point. I can definitively see how TTLs are a problem for including non-PK columns from
the base table into a MV PK. That said, as far as I can tell that's a problem even with a
single column that is not in the original PK. Yet, it's supposed to be supported by the patch.
How does it work? What happen once that column expires?

bq. This means that we will have to insert a NULL value for all unset columns, as well as
all tombstone'd columns, since regular columns are not explicitly null.

That part I don't follow.


> Materialized Views (was: Global Indexes)
> ----------------------------------------
>
>                 Key: CASSANDRA-6477
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-6477
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Carl Yeksigian
>              Labels: cql
>             Fix For: 3.0 beta 1
>
>         Attachments: test-view-data.sh, users.yaml
>
>
> Local indexes are suitable for low-cardinality data, where spreading the index across
the cluster is a Good Thing.  However, for high-cardinality data, local indexes require querying
most nodes in the cluster even if only a handful of rows is returned.



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

Mime
View raw message