[jira] [Commented] (CASSANDRA-4285) Atomic, eventually-consistent batches

["Jonathan Ellis (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/CASSANDRA-4285?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13434222#comment-13434222 ] 

Jonathan Ellis commented on CASSANDRA-4285:
-------------------------------------------

I think the above overcomplicates things a bit.

The idea with sharding was to

# mitigate wide batchlog rows
# spread batchlog load better across the cluster
# avoid having to fail a batch write if *the* batchlog replica for a given coordinator is down

If we make the batchlog *replica* in charge of replay, these all go away or get simpler.

# replica can examine batchlog entries and convert to hints if they are older than 2x write timeout.  We expect very few of these so the inefficiency (over having coordinator do it only after restart) is not a Big Deal.  This also simplifies replay a great deal (now coordinator no longer has poll for the BL replicas to come up)
# since we never have to do a non-local *read* of the batchlog, we can use a WriteAnywhereStrategy that just picks a random node in the local DC
# can be mitigated by making our hypothetical WAS FD-aware, or simply by going to RF=2 (and doing CL.ONE writes).

I like having replay be local and automatic a great deal, over having the coordinator do it (which implies having some manual? failover mechanism when the coordinator is down for good).

Note that we'd want to define batchlog with LocalStrategy (in system ks), we'd manually invoke WriteAnywhereStrategy from StorageProxy.  Thinking about it, we probably wouldn't want an actual Strategy, just similar code, since we don't actually depend on the row key to pick replicas.

                
> 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
>            Assignee: 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