[
https://issues.apache.org/jira/browse/CASSANDRA-6477?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14630926#comment-14630926
]
Sylvain Lebresne commented on CASSANDRA-6477:
---------------------------------------------
bq. Made the base -> view mutations async. Once we write to the local batchlog,
we don't care if the actual mutations are sent, it's best effort. So we can
fire and forget these and update the base memtable.
That's correct from an eventual consistency point of view, but I'm pretty sure
this breaks the CL guarantees for the user. What we want is that if I write at
{{CL.QUORUM}} the base table, and then read my MV at {{CL.QUORUM}}, then I'm
guaranteed to see my previous update. But that requires that each replica does
synchronous updates to the MV, and with the user CL. Writing a local batchlog
is not enough in particular since it doesn't give any kind of guarantee of the
visibility of the update. See my next comment though on that local batchlog.
bq. Made the Base -> View batchlog update local only
I've actually never understood why we do a batchlog update on the base table
replicas (and so I think we should remove it, even though that's likely not the
most costly one). Why do we need it? If my reasoning above is correct, the
coordinator batchlog is enough to guarantee durability and eventual consistency
because we will replay the whole mutation until a QUORUM of replica
acknowledges success.
> 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)
