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