[
https://issues.apache.org/jira/browse/CASSANDRA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13284466#comment-13284466
]
Jonathan Ellis commented on CASSANDRA-4285:
-------------------------------------------
The DCL should be in its own keyspace, both for hygiene and so replication
strategy can be tuned independently. In particular I think RF=1 will be Good
Enough for 90% of use cases; remember that our goal here is to handle the case
when the coordinator has sent part of a batch out, but not the entire thing.
Once the entire batch is sent out to one replica, HH and repair can take care
of making sure that gets to the rest of the cluster.
So it's only the relatively narrow window of sending out the rows in the batch
that we need to worry about here -- once that is done we don't care about
preserving the original batch anymore. The coordinator itself is thus
effectively a replica for the useful part of the operation, so a single other
machine should be adequate protection.
Unfortunately we don't have a way to say "store this replica anywhere but
locally." So maybe we do need to go to RF=2 to make sure we have another
*non-local* copy.
Alternatively maybe we could special case this and write a hint elsewhere if we
detect that the DCL replica would be local.
> Atomic, eventually-consistent batches
> -------------------------------------
>
> Key: CASSANDRA-4285
> URL: https://issues.apache.org/jira/browse/CASSANDRA-4285
> Project: Cassandra
> Issue Type: New Feature
> Components: API, Core
> Reporter: Jonathan Ellis
>
> I discussed this in the context of triggers (CASSANDRA-1311) but it's useful
> as a standalone feature as well.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
