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

Matthias Broecheler commented on CASSANDRA-6477:
------------------------------------------------

My 2 cents on the {{null}} discussion: 
It needs to be supported that rows are ignored in the view if their column 
values would lead to null values in the primary key of the view. Otherwise, 
view maintenance becomes impractical for sparsely populated tables. Imagine you 
have a large table of users but only 10% or so of those have a SSN. If you 
create a view by SSN you are creating a hotspot which makes it impractical.
However, there are situations where including {{null}} values is perfectly 
reasonable under the assumption that the combination of the remaining primary 
key column values leads to a sufficiently high selectivity. Problem is, without 
the user giving us some sort of information the two cases won't be 
distinguishable.
Hence, it may make sense to introduce a {{WITH NULL}} or {{WITHOUT NULL}} 
qualifier in the view definition to give the user control over the behavior 
with {{WITHOUT NULL}} being the default option since its safer (i.e. lower 
likelihood of hotspots).

> 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)

Reply via email to