[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14629865#comment-14629865
]
Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------
bq. For example, if my base table was id, name, and address, with id as the
PK, I couldn't have MV with just name or address as the PK key according to
this requirement, right?
That's correct. We have no way of guaranteeing that your "just name or address"
uniquely identifies a row in the base table (and most probably, it doesn't). So
what would we do when multiple entries in the base class conflict in the MV?
The only option would be to keep the most recent entry, but that would be
confusing as hell and we don't want to do that (at the very least, not in that
initial ticket). And while we could allows some form of aggregation in that
case, that is also definitively at best a future feature.
But more importantly, it's not really limiting at all. If you want to have a MV
to search users by names for instance, just put the name first in the MV PK. To
have the rest of the column in the PK won't prevent you for doing your search
by name, it'll just guarantee you that you do see all your using have that
name, not just the last one updated.
> 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)
