cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jack Krupansky (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-6477) Materialized Views (was: Global Indexes)
Date Fri, 17 Jul 2015 15:52:09 GMT

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

Jack Krupansky commented on CASSANDRA-6477:
-------------------------------------------

bq. multiple MVs being updated

It would be good to get a handle on what the scalability of MVs per base table is in terms
of recommended best practice. Hundreds? Thousands? A few dozen? Maybe just a handful, like
5 or 10 or a dozen?

I hate it when a feature like this gets implemented without scalability in mind and then some
poor/idiot user comes along and tries a use case which is way out of line with the implemented
architecture but we provide no guidance as to what the practical limits really are (e.g.,
number of tables - thousands vs. hundreds.)

It seems to me that the primary use case is for query tables, where an app might typically
have a handful of queries and probably not more than a small number of dozens in even extreme
cases.

In any case, it would be great to be clear about the design limit for number of MVs per base
table - and to make sure some testing gets done to assure that the number is practical.

And by design limit I don't mean a hard limit where more will cause an explicit error, but
where performance is considered acceptable.

Are the MV updates occurring in parallel with each other, or are they serial? How many MVs
could a base table have before the MV updates effectively become serialized?

> 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