cassandra-commits mailing list archives

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

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

 Brian Hess commented on CASSANDRA-6477:
----------------------------------------

A question to behavior here.  If we do the following
{noformat}
INSERT INTO t (k, t, v) VALUES (0, 0, 0) USING TTL 1000;
UPDATE t SET v = null WHERE k = 0 AND t = 0;
INSERT INTO t (k, t) VALUES (1, 1) USING TTL 1000;
{noformat}

Then, doing a 
{noformat}
SELECT * FROM t;
{noformat}
would result in getting both rows: (0, 0, null) and (1, 1, null)

However, if we have the view also have a null for the first row, so it would be (0, null,
0), wouldn't we also expect to see a row for (1, null, 1)?
The fact that a cell was non-null and is now null shouldn't really have any different behavior
than if it was null from the start.

Another point - I think the primary use case will be to mimic query tables.  That is, the
MV will have the same columns in its primary key as the base table's, but with different partition
keys and different orders for clustering columns.  I could be wrong, but that seems like the
biggest use case.  And in that use case the keys are all non-null.

> 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