[jira] [Commented] (CASSANDRA-7056) Add RAMP transactions

["Matthias Broecheler (JIRA)" <ji...@apache.org>]

    [ 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)