cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carl Yeksigian (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
Date Tue, 14 Jul 2015 15:25:09 GMT


Carl Yeksigian commented on CASSANDRA-6477:

bq. 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?

Because that is the only column which is supported, we TTL the row in the view so that it
is taken care of the same as the base TTL. The difference here would be that there would also
need to be a new value created which is the NULL that the TTL will result in after it has
expired. We would either need special logic to handle a TTL on compaction (and lose some eventual
consistency), or generate a future timestamped value for the NULL whenever we create a TTL
that will become valid when the TTL expires on the base and view columns.

bq. That part I don't follow.

We don't have semantics for regular columns to be set null, instead that indicates that they
are tombstones. We can't distinguish between an explicitly set NULL and one that happened
because we either tombstoned the columns or we never set the included columns, so we will
have to use the NULL value for all unset and tombstoned columns.

> Materialized Views (was: Global Indexes)
> ----------------------------------------
>                 Key: CASSANDRA-6477
>                 URL:
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: API, Core
>            Reporter: Jonathan Ellis
>            Assignee: Carl Yeksigian
>              Labels: cql
>             Fix For: 3.0 beta 1
>         Attachments:, 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

View raw message