cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Dave Revell (JIRA)" <j...@apache.org>
Subject [jira] Commented: (CASSANDRA-1684) Entity groups
Date Fri, 11 Mar 2011 07:40:59 GMT

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

Dave Revell commented on CASSANDRA-1684:
----------------------------------------

As jbellis says in the description, atomic batches and entity group locality are cool and
useful. But we should be clear that Cassandra's entity groups would be a different beast than
Megastore's entity groups, and wouldn't have the same consistency properties unless some un-Cassandra-like
changes were made.

In Megastore, transactions can maintain arbitrary consistency constraints among items in an
entity group, since there is a Paxos-agreed total order of transactions. Cassandra has so
far avoided fancy distributed agreement like this. For example, imagine running (in Cassandra)
two different transactions on two different replicas and imagine what mishmash of the two
outcomes you'd get once timestamp-based conflict resolution happened. In Megastore one of
the transactions would abort. Are we willing to add Paxos?

G-Store's ownership transfer protocol also seems very anti-Cassandra-philosophy with its concept
of single-replica item ownership.

I'd be happy to be corrected on any of this. I think Megastore-like entity groups are an exciting
idea but perhaps make more sense on top of HBase :)

> Entity groups
> -------------
>
>                 Key: CASSANDRA-1684
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-1684
>             Project: Cassandra
>          Issue Type: New Feature
>          Components: Core
>            Reporter: Jonathan Ellis
>            Assignee: Sylvain Lebresne
>             Fix For: 0.8
>
>   Original Estimate: 80h
>  Remaining Estimate: 80h
>
> Supporting entity groups similar to App Engine's (that is, allow rows to be part of a
parent "entity group," whose key is used for routing instead of the row itself) allows several
improvements:
>  - batches within an EG can be atomic across multiple rows
>  - order-by-value queries within an EG only have to touch a single replica even with
RandomPartitioner

--
This message is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira

Mime
View raw message