cassandra-commits mailing list archives

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

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

Mime
View raw message