[
https://issues.apache.org/jira/browse/CASSANDRA-225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12724668#action_12724668
]
Jonathan Ellis commented on CASSANDRA-225:
------------------------------------------
1. 5 seconds to elect a new master under ideal conditions isn't the point. The
point is that when you partition, the side with a minority of nodes can't
accept writes indefinitely. Or reads either, depending on how strict you are
being.
This alone is a deal-breaker for me; "always writable" is a major design goal
for both Dynamo and Cassandra. (If you don't require a majority to elect a
master, it's not really a master and all your benefits go away.) This is the
wrong direction to move in; I think Jonas from Google was right when he said at
NoSQL that the world is moving towards eventual consistency.
2. Absent a full, production-tested implementation of mastered writes (the
devil is in the details!) there is no way to say for sure, but my intuition is
that eventual consistency + repair is going to be significantly less complex.
And trying to support _both_ models as Sandeep originally suggested is just a
nightmare.
> Support mastered writes
> -----------------------
>
> Key: CASSANDRA-225
> URL: https://issues.apache.org/jira/browse/CASSANDRA-225
> Project: Cassandra
> Issue Type: New Feature
> Affects Versions: 0.4
> Environment: all
> Reporter: Sandeep Tata
> Assignee: Sandeep Tata
> Attachments: 225.patch
>
>
> Writes to a row today can be run on any of the replicas that own the row. An
> additional set of APIs to perform "mastered" writes that funnel through a
> primary is important if applications have some operations that require higher
> consistency. Test-and-set is an example of one such operation that requires a
> higher consistency guarantee.
> To stay true to Cassandra's performance goals, this should be done in a way
> that does not compromise performance for apps that can deal with lower
> consistency and never use these APIs. That said, an app that mixes higher
> consistency calls with lower consistency calls should be careful that they
> don't operate on the same data.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
