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