cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Aleksey Yeschenko (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
Date Wed, 29 Jul 2015 11:17:09 GMT


Aleksey Yeschenko commented on CASSANDRA-6477:

I know we already have CASSANDRA-9736, but in the meantime {{ALTER TABLE}} should not be allowed
to alter MVs (don't want it to be accidentally forgotten).

Instead of having a {{ConcurrentHashSet}} in {{Schema}} (named {{materializedViewList}}, for
some reason), MVness of a table should be a boolean flag, or, better, an enum, in {{CFMetaData}}.

There seems to be no validation on Thrift side against modifying a view directly (think {{CassandraServer}}).

It's possible to create an index, or add a trigger, to an MV. I think the latter would just
break, and not sure if we want to ever support the former.

Security is not handled completely properly. {{CREATE MATERIALIZED VIEW}} is requiring {{SELECT}}
on the base table. It shouldn't. We should be checking for {{SELECT}} permission against the
base table every query against MVs (a check on {{CREATE}} is a one-time check, and then permission
can go away at any time). May also look into new permissions altogether for view DDL /cc [~beobal]

We need to think where MVs are on the hierarchy. Are they on the same level as secondary indexes,
or on the same level as other tables, UDTs, UDFs, and UDAs? In the latter case, we need new
events for the native protocol.

It would be my strong preference that MVs do not reuse {{system_schema.tables}} to store their
metadata, even if it means some duplication. (for schema code, after the next CASSANDRA-9712
comment that will factor-out {{TableParams}}, the duplication will be less of an issue). The
way it's currently done, with a 'link' table, I'm not a fan of. One table with those two merged
should be enough.

We are committed to supporting proper {{WHERE}} clause in the future (and CASSANDRA-9778).
I expect the necessary schema to support it to be in 3.0 GA, for forward compatibility. Altering
schema tables is not exactly trivial, and may force us to have to wait until 4.0 for those

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