cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Matthias Broecheler (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (CASSANDRA-7056) Add RAMP transactions
Date Thu, 03 Jul 2014 04:01:26 GMT

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

Matthias Broecheler commented on CASSANDRA-7056:
------------------------------------------------

Regarding use cases for this feature, it would be highly useful for TitanDB (http://titan.thinkaurelius.com/).
Titan denormalizes the data and maintains a number of 2i in order to expose a graph data model
that supports efficient querying. We are seeing a number of use cases in health and finance
where having atomic visibility is a requirement to avoid phenomena like "phantom vertices"
and "half-edges". 

Titan already supports the notion of a transaction and so I experimented with some naive/limited
approaches for building this on top of C*. While RAMP is much more sophisticated and better
thought through, here is what I learned in case it helps (ignoring deletes). Appending a lot
of meta-data to columns had a pretty dramatic performance impact because Titan creates a lot
of cells (wide rows). If you implement this in C* natively that wouldn't need to be returned
to the client, but it would still bloat all data structures. More importantly, however, that
overhead is always there and cannot be configured on a per transaction basis. In our cases
there is a mixture of transactions few of which require the atomicity and most of which don't.
My guess would be that for RAMP-Fast with linear transaction size storage overhead similar
issues would arise for databases with lots of small cells and large tx.

Appending a unique transaction id (Titan assigns those) and maintaining a transaction log
(we needed that anyway for a different reason) has little impact on the normal transactions
whereas atomic read transactions paid extra read penalties. In spirit, that seems similar
to RAMP-Small. To me, this approach is more desirable because the (big) performance penalty
only applies to those transactions that need it.

Again, these experiences are based on a different/naive implementation and with a particular
work load consisting of many small cells.

> Add RAMP transactions
> ---------------------
>
>                 Key: CASSANDRA-7056
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-7056
>             Project: Cassandra
>          Issue Type: Wish
>          Components: Core
>            Reporter: Tupshin Harper
>            Priority: Minor
>
> We should take a look at [RAMP|http://www.bailis.org/blog/scalable-atomic-visibility-with-ramp-transactions/]
transactions, and figure out if they can be used to provide more efficient LWT (or LWT-like)
operations.



--
This message was sent by Atlassian JIRA
(v6.2#6252)

Mime
View raw message