[
https://issues.apache.org/jira/browse/CASSANDRA-13066?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16079742#comment-16079742
]
Kurt Greaves commented on CASSANDRA-13066:
------------------------------------------
+1 what Paulo said. Append only MV's really don't make sense at the moment
because of the forced read before write, so really there is little benefit in
this improvement unless we group it with functionality to enforce append-only
MV's. Also, I think it's generally a bad idea to provide options that will
break consistency in known circumstances. Seems to me this option would kind of
end up like consistent.rangemovement which is a constant source of problems for
users that don't fully understand the implications. You can guarantee people
will enable this for MV's that are not append-only.
Would there be any objection to move this to be a sub-task of CASSANDRA-9779?
> Fast streaming with materialized views
> --------------------------------------
>
> Key: CASSANDRA-13066
> URL: https://issues.apache.org/jira/browse/CASSANDRA-13066
> Project: Cassandra
> Issue Type: Improvement
> Components: Materialized Views, Streaming and Messaging
> Reporter: Benjamin Roth
> Assignee: Benjamin Roth
> Fix For: 4.0
>
>
> I propose adding a configuration option to send streams of tables with MVs
> not through the regular write path.
> This may be either a global option or better a CF option.
> Background:
> A repair of a CF with an MV that is much out of sync creates many streams.
> These streams all go through the regular write path to assert local
> consistency of the MV. This again causes a read before write for every single
> mutation which again puts a lot of pressure on the node - much more than
> simply streaming the SSTable down.
> In some cases this can be avoided. Instead of only repairing the base table,
> all base + mv tables would have to be repaired. But this can break eventual
> consistency between base table and MV. The proposed behaviour is always safe,
> when having append-only MVs. It also works when using CL_QUORUM writes but it
> cannot be absolutely guaranteed, that a quorum write is applied atomically,
> so this can also lead to inconsistencies, if a quorum write is started but
> one node dies in the middle of a request.
> So, this proposal can help a lot in some situations but also can break
> consistency in others. That's why it should be left upon the operator if that
> behaviour is appropriate for individual use cases.
> This issue came up here:
> https://issues.apache.org/jira/browse/CASSANDRA-12888?focusedCommentId=15736599&page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel#comment-15736599
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
---------------------------------------------------------------------
To unsubscribe, e-mail: commits-unsubscr...@cassandra.apache.org
For additional commands, e-mail: commits-h...@cassandra.apache.org
