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