You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Audience: All Cassandra Users and Developers
User Impact: Support for fast general purpose transactions

Motivation

Users must expend significant effort to modify their database consistently while maintaining scalability. Even simple transactions involving more than one partition may become complex and error prone, as a distributed state machine must be built atop the database. Conversely, packing all of the state into one partition is not scalable.

Performance also remains an issue, despite recent Paxos improvements: latency is still twice its theoretical minimum over the wide area network, and suffers particularly badly under contention.

This work aims to improve Cassandra to support fast general purpose transactions. That is, those that may operate over any set of keys in the database atomically, modifying their contents at-once, with any action conditional on the existing contents of any key.

Goals

  • General purpose transactions (may operate over any keys in the database at once)
  • Strict-serializable isolation
  • Optimal latency: one wide area round-trip for all transactions under normal conditions
  • Optimal failure tolerance: latency and performance should be unaffected by any minority of replica failures
  • Scalability: there should be no bottleneck introduced
  • Should have no intrinsic limit to transaction complexity
  • Must work on commodity hardware



  • No labels