[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14632354#comment-14632354
]
Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------
bq. We have designed it as async
Unless I've missed some part of how "we designed it", that's actually the
opposite. In fact, the reasoning I expressed in [my previous
comment|https://issues.apache.org/jira/browse/CASSANDRA-6477?focusedCommentId=14630910&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-14630910],
which to the best of my knowledge is the reasoning being the design currently
implemented, was _relying_ on sync MV updates for correction.
I say "was" because all this probably doesn't really matter since [~benedict]
has a point: with or without sync MV updates, there is holes in this design.
Both because, to repeat what he says, replaying mutations from the coordinator
batch log doesn't work if the mutation was applied on the base replica but not
the paired MV, but also because repair can screw us up by propagating
base-table updates behind our backs without going through the MV update code
path. In other words, the design as implemented is _not_ eventually consistent
(and in the case of the repair problem, you don't even need any failure to get
permanent inconsistencies, just unlucky timing).
And I don't see an easy tweak to the implemented design that would fix both
problems. [~benedict] suggestion above of "batch-logging deltas" _might_ work
for the first problem, but we'd need to look at the details and convince
ourselves it does work in all cases before even thinking of implementing it (at
which point it will unlikely be a minor change to the current patch), and that
still leave the repair problem to solve. And so it kind of put us back to the
drawing board, and I think ideas around using cell reconciliation to generate
fix to MVs (as was initially considered) would also be worth reconsidering (I'm
not saying I have anything close to a complete design in mind, and there is for
sure a number of problems to solve in that case too, but it does feel like it
would handle the repair problem natively if we can make it work, which is a
plus).
Anyway, I would humbly suggest we focus on that problem first, because unless
we're willing to release MVs with "hopeful consistency" (which, to put it
mildly, I'm not a fan), this might well compromise a 3.0 release.
> 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)
