1. 2

All too often, NoSQL is associated with having to compromise enterprise features common in the RDBMS space, such as support for ACID transactions. The reality however, is that it has been possible to do transactions with NoSQL for quite some time. This article walks through an example by way of Java code.


  2. 4

    Most NoSQL databases that avoid transactions (providing either multi-key or multi-statement semantics) do so to reduce the amount of consensus that must be reached in the cluster, because consensus is expensive in terms of network traffic, and hurts latency.

    I don’t know that much about MarkLogic’s clustering, and I’m finding it hard to learn much in 10 minutes of googling. Do you know what kind of clustering MarkLogic supports? Does it allow for sharding? What kinds of guarantees does it give to transactions that need to touch multiple nodes? If you use transactions like this, how do they perform?

    Here’s the part that bugs me:

    it provides multi-statement transaction capabilities to the Java developer without sacrificing the other benefits we have come to expect from NoSQL, such as agility and scale-out capability across commodity hardware

    TANSTAAFL, so I find it really hard to believe this statement. There’s a tradeoff somewhere and this article isn’t admitting it. Does anyone know what the tradeoff is?

    For reference, the product I work on, TokuMX, also is a NoSQL database that supports ACID transactions, but we limit what you can do with them if you’re sharding (currently looking at reducing those restrictions, email me if you want to work on those kinds of things).

    @aphyr: is MarkLogic on the Jepsen list? I’d be curious to see what you can figure out.