cassandra-commits mailing list archives

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

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

Benedict commented on CASSANDRA-6477:
-------------------------------------

bq. As well, it does add potentially another hop,

No, it removes a hop. Several hops: Currently we write to the batch log synchronously before
we do anything else. In fact we do it twice. These are all double-hops. I'm proposing removing
all of them, by exploiting the fact that typically the coordinator is an owner, and so as
soon as two owners have the mutations in their local batch logs we're about as good as we'll
get that these mutations _will_ be applied, and if they _aren't_ going to be applied they
also won't partially apply.

To make a more general statement: I think there is perhaps a failure to appreciate the difficulty
of the problem Sylvain was raising, around ensuring we do not end up with a corrupted MV that
we have no idea how to repair. In fact, I very much doubt we are going to achieve this no
matter how hard we try, and this is going to end up making us look pretty bad. If a user fails
to keep their views in sync, that's one thing, but if we do it's another. I'm talking about
even _eventually_ consistent here. There are a lot of nook and cranny failure scenarios and
that's before we consider repair. Which, as I say, I suspect completely ruins us. Ironically,
of course :)

> 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