cassandra-commits mailing list archives

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

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

Jonathan Ellis commented on CASSANDRA-6477:
-------------------------------------------

bq. how do you take the token on a null partition key

There are a number of options.  Make it the first value in the token space, or the same as
the token of empty blob, or the same as the token for a zero-element tuple, for instance.
 It doesn't really matter since token collisions are acceptable now.

bq. if you used it for clustering keys the query syntax would be non-standard 

I'm proposing that the encoding should be internal, not exposed to the user.  Fundamentally
we need to distinguish that (A, null) and (null, B) are different things.  Whether we use
a tuple or some custom encoding to do that I don't care.

bq. It wouldn't be any different than how we enforce it for PK today 

Which is exactly the problem, the syntax itself enforces that the PK is specified because
that is how the row being updated is identified.  But with this we'd have to require the user
to add {{, not_null_column=X}} as part of the SET clause for every UPDATE.

> 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